Re: [yocto] qemu boot fail(root-nfs: unknown option: mountprog=21111)

[Bruce Ashfield]

On 11-09-08 11:09 AM, Scott Garman wrote:
> On 09/07/2011 10:49 PM, 蔡振军 wrote:
>> Hi ALL
>>
>> QEMU run well with a pre-build kernel image from yocto site. Now just
>> change the kernel to one built myself, some error information appeared
>> about nfs. My kernel image version is 2.6.35 configured by
>> versatile_defconfig. Error information as following:
>>
>> “root-nfs: unknown option: mountprog=2”,this message search nothing
>> on google.
>>
>> Is there something wrong with .config? Add normally is there some
>> special configuration I should do with kernel to fit QEMU?
> 
> Hi Feye,
> 
> The linux-yocto kernel has patches in it to enable booting via a
> userspace NFS server, which needs to use high port numbers for its
> mountd and nfsd daemons. You will need to include these patches in your
> custom kernel if you wish to continue using our userspace NFS boot method.

I already replied to this last night:

"You can't change out the kernel version / tree and expect to use the full
functionality provided by the linux-yocto kernel. In this case there are
changes to NFS and rpc to support alternate rpc ports being used to support
usermode NFS. You would need to port and test the patches for this
which can be found on yocto/standard/base"

Cheers,

Bruce

"

> 
> Bruce, can you point Feye to this patchset?
> 
> Scott
> 

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

Re: [yocto] [PATCH 0/2] [KERNEL] Cover letter for seperating 10/100 LAN feature from 1G and 10G

[Bruce Ashfield]

On 11-09-08 06:05 PM, Saxena, Rahul wrote:

Cover letter for separating 10/100 LAN feature from 1G and 10G.
Typically a machine does not need both of 10/100 and 1G/10G drivers.


The change looks fine, and I'd agree that this is a useful split.
BUT (there's always a but), there are a set of boards that are currently
including the e1 feature that would currently be getting the e100,
and they'll no longer have it.

./bsp/common-pc/common-pc.scc:include features/intel-e1/intel-e1.scc
./bsp/fri2/fri2.scc:include features/intel-e1/intel-e1.scc
./bsp/fishriver/fishriver.scc:include features/intel-e1/intel-e1.scc
./bsp/romley/romley.scc:include features/intel-e1/intel-e1.scc
./bsp/emenlow/emenlow.scc:include features/intel-e1/intel-e1.scc
./bsp/crownbay/crownbay.scc:include features/intel-e1/intel-e1.scc
./bsp/common-pc-64/common-pc-64.scc:include 
features/intel-e1/intel-e1.scc


In particular the common-pc really does want that config (for qemu).
So we should do the split, but also update all those boards to include
your new feature as part of this change.

Can you try and resend with that addition ? You don't need to built/boot,
just make the touches to the files listed above and I can take care of
the rest.

Bruce



Signed-off-by: Rahul Saxena

Rahul Saxena (2):

Remove 10/100 LAN support. 10/100 LAN will be configured by seperate

files

Added seperate feature for 10/100 LAN support

.../features/intel-e1/intel-e100.cfg | 2 ++

.../features/intel-e1/intel-e100.scc | 1 +

.../features/intel-e1/intel-e1.cfg | 1 -

3 files changed, 3 insertions(+), 1 deletions(-)

create mode 100644
meta/cfg/kernel-cache/features/intel-e1/intel-e100.cfg

create mode 100644
meta/cfg/kernel-cache/features/intel-e1/intel-e100.scc



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


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

Re: [yocto] [PATCH 0/3] [KERNEL] Cover letter for seperating 10/100 LAN feature from 1G and 10G

[Bruce Ashfield]

On 11-09-08 07:30 PM, Saxena, Rahul wrote:

Cover letter for separating 10/100 LAN feature from 1G and 10G.
Typically a machine does not need both of 10/100 and 1G/10G drivers.


These look good now, but when I went to merge the patches I see they
are multipart, and html-ized. Which is causing me considerable pain
in getting them applied.

Can you resend the patches via git-send-email ? Or push them to a
contrib branch ? If you are not sure about how to do either of these,
we can help and Tom may have some practical tips to share.

Cheers,

Bruce



Signed-off-by: Rahul saxenarahul.sax...@intel.com


Rahul Saxena (3):

Remove 10/100 LAN support. 10/100 LAN will be configured by seperate

files

Added seperate feature for 10/100 LAN support

Added e100 feature configuration to remaining boards

.../kernel-cache/bsp/common-pc-64/common-pc-64.scc | 1 +

meta/cfg/kernel-cache/bsp/common-pc/common-pc.scc | 1 +

meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc | 1 +

meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc | 2 +-

meta/cfg/kernel-cache/bsp/fishriver/fishriver.scc | 1 +

meta/cfg/kernel-cache/bsp/fri2/fri2.scc | 1 +

meta/cfg/kernel-cache/bsp/romley/romley.scc | 1 +

.../features/intel-e1/intel-e100.cfg | 2 ++

.../features/intel-e1/intel-e100.scc | 1 +

.../features/intel-e1/intel-e1.cfg | 1 -

10 files changed, 10 insertions(+), 2 deletions(-)

create mode 100644
meta/cfg/kernel-cache/features/intel-e1/intel-e100.cfg

create mode 100644
meta/cfg/kernel-cache/features/intel-e1/intel-e100.scc



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


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

Re: [yocto] [PATCH 0/3] [KERNEL] Cover letter for seperating 10/100 LAN feature from 1G and 10G

[Bruce Ashfield]

On 11-09-09 05:28 PM, Saxena, Rahul wrote:

Hi Bruce,

I have pushed the pacthes to meta-intel-contrib, link given below:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/tree/?h=10-100-patch

Let me know if this works.


This suffers a similar problem:

git am 
../meta-intel-contrib/0001-Remove-10-100-LAN-support.-10-100-LAN-will-be-config.patch

Patch format detection failed.

If it's easier for you, just git format-patch HEAD^^^ and attach
the three patches to an email and send them along .. they should be
safe that way.

Bruce



Thanks
Rahul

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Friday, September 09, 2011 11:52 AM
To: Saxena, Rahul
Cc: yocto@yoctoproject.org; Bruce Ashfield; Zanussi, Tom
Subject: Re: [yocto] [PATCH 0/3] [KERNEL] Cover letter for seperating 10/100 
LAN feature from 1G and 10G

On 11-09-08 07:30 PM, Saxena, Rahul wrote:

Cover letter for separating 10/100 LAN feature from 1G and 10G.
Typically a machine does not need both of 10/100 and 1G/10G drivers.


These look good now, but when I went to merge the patches I see they
are multipart, and html-ized. Which is causing me considerable pain
in getting them applied.

Can you resend the patches via git-send-email ? Or push them to a
contrib branch ? If you are not sure about how to do either of these,
we can help and Tom may have some practical tips to share.

Cheers,

Bruce



Signed-off-by: Rahul saxenarahul.sax...@intel.com
<mailto:rahul.sax...@intel.com>

Rahul Saxena (3):

Remove 10/100 LAN support. 10/100 LAN will be configured by seperate

files

Added seperate feature for 10/100 LAN support

Added e100 feature configuration to remaining boards

.../kernel-cache/bsp/common-pc-64/common-pc-64.scc | 1 +

meta/cfg/kernel-cache/bsp/common-pc/common-pc.scc | 1 +

meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc | 1 +

meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc | 2 +-

meta/cfg/kernel-cache/bsp/fishriver/fishriver.scc | 1 +

meta/cfg/kernel-cache/bsp/fri2/fri2.scc | 1 +

meta/cfg/kernel-cache/bsp/romley/romley.scc | 1 +

.../features/intel-e1/intel-e100.cfg | 2 ++

.../features/intel-e1/intel-e100.scc | 1 +

.../features/intel-e1/intel-e1.cfg | 1 -

10 files changed, 10 insertions(+), 2 deletions(-)

create mode 100644
meta/cfg/kernel-cache/features/intel-e1/intel-e100.cfg

create mode 100644
meta/cfg/kernel-cache/features/intel-e1/intel-e100.scc



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




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

Re: [yocto] kernel panic when boot core-image-sato-sdk for qemux86

[Bruce Ashfield]

On 11-09-09 07:09 PM, Zhang, Jessica wrote:

Hi,

Has anybody ran into kernel panic when boot up core-image-sato-sdk for
qemux86. I’ve been having this issue with several clean build for two
days. And my latest build tree is a freshly cloned tree against
poky-master with commit:

commit 20dbf0024385eaef61a04d8773fd7640e3c8cc6d

Author: Richard Purdie 

Date: Fri Sep 9 19:07:40 2011 +0100

The qemu kernel panic messages are:

INIT: version 2.88 booting

Init[1]: segfault at 38 ip 495076c7 sp bfd9b60c error 4 in
libc-2.13.so[49492000+15f000]

Init[1]: segfault at 16 ip 0804b3c7 sp bfd9b280 error 4 in
init.sysvinit[8048000+7000]

Kernel panic – not syncing: Attempted to kill init!

Pid: 1, comm: init Not tainted 3.0.4-yocto-standard+ #1

Any idea?


Since I've been at Linux plumbers since Wednesday, I can confirm
that nothing has changed in the kernel itself. And I just booted
an older userspace with a brand new kernel a few minutes ago. That means
that something else has changed which is producing the segfault
(toolchain, libs, .. something) and tossing you out to the panic.

If you try an older filesystem with your recent kernel, do you see
a good boot.

Bruce



Thanks,

Jessica



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


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

Re: [yocto] kernel panic when boot core-image-sato-sdk for qemux86

[Bruce Ashfield]

On 11-09-10 12:28 PM, Richard Purdie wrote:

On Sat, 2011-09-10 at 09:21 -0600, Gary Thomas wrote:

On 2011-09-10 07:13, Gary Thomas wrote:

On 2011-09-09 17:09, Zhang, Jessica wrote:

Hi,

Has anybody ran into kernel panic when boot up core-image-sato-sdk for qemux86. 
I’ve been having this issue with several clean build for two days. And my 
latest build tree is a
freshly cloned tree against poky-master with commit:

commit 20dbf0024385eaef61a04d8773fd7640e3c8cc6d

Author: Richard Purdie

Date: Fri Sep 9 19:07:40 2011 +0100

The qemu kernel panic messages are:

INIT: version 2.88 booting

Init[1]: segfault at 38 ip 495076c7 sp bfd9b60c error 4 in 
libc-2.13.so[49492000+15f000]

Init[1]: segfault at 16 ip 0804b3c7 sp bfd9b280 error 4 in 
init.sysvinit[8048000+7000]

Kernel panic – not syncing: Attempted to kill init!

Pid: 1, comm: init Not tainted 3.0.4-yocto-standard+ #1


Verified - fails for me here as well. A Bruce said, a build from just a few days
ago did work. Note: I only tried core-image-sato

As far as I can tell, the only packages that were rebuilt since my last go on
Aug 31 were virtual/kernel&  perf

Looks like it's something to do with kernel changes.



Actually, I forgot that qemux86 also uses i586 packages, so there were quite a
few other packages changed since Aug 31.  You can see the lists at
http://www.mlbassoc.com/poky/qemux86-rpms



I've just tested qemux86 and qemuarm images and both of these were fine
(apart from pango issues which I locally reverted the change in question
for). I'm a little puzzled why things are therefore failing for people
but I would like to get to the bottom of it...


As would I! I just audited the kernel changes, and there's nothing that
should cause anything so severe. My build and boot of course worked as
well.

The grand total of changes since the 3.0.4 update are:

  3c9ebee meta: re-enable utrace feature for linux-yocto
  82140b9 meta: re-enable systemtap feature for linux-yocto
  258af0b meta: update kver to v3.0.4

And both of those were merged and boot tested a while ago.

And the reports of different results from the autobuilder to local machines.
Really makes me wonder about what's really being built and if
something strange is being fetched.

Jessica/Gary: if you explicitly disable utrace, I wonder if that
makes a difference, since it's the only change that should even
have a chance to cause runtime issues. (to disable it, just toss
a config frag with "# CONFIG_UTRACE is not set" and build, or just
confirm that it is off via menuconfig).

Cheers,

Bruce




Cheers,

Richard





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


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

Re: [yocto] [PATCH][linux-yocto] preempt-rt/base: correct 3.0.3->3.0.4 mismerge for, stop_machine.c

[Bruce Ashfield]

On 11-09-13 3:33 PM, Darren Hart wrote:

Commit 0b805cce57f61a244eb3b8fce460b14f1be442b3 dropped a change making
stop_cpus_mutex non-static, resulting in a build failure for 3.0.4-rt
kernels.

Restore the move to non-static from commit
6857336c7fddaf460a13adc0c395698fcf9423ff.


Acked. I'm doing a kernel merge tomorrow, so this will be part of
that update.

Bruce



Reported-by: Kishore Bodke
Signed-off-by: Darren Hart
CC: Bruce Ashfield
---
  kernel/stop_machine.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index c54d0fa..d6b3ac2 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -150,8 +150,8 @@ void stop_one_cpu_nowait(unsigned int cpu, cpu_stop_fn_t 
fn, void *arg,
cpu_stop_queue_work(&per_cpu(cpu_stopper, cpu), work_buf);
  }

+DEFINE_MUTEX(stop_cpus_mutex);
  /* static data for stop_cpus */
-static DEFINE_MUTEX(stop_cpus_mutex);
  static DEFINE_MUTEX(stopper_lock);
  static DEFINE_PER_CPU(struct cpu_stop_work, stop_cpus_work);



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

Re: [yocto] [PATCH 1/1] btrfs: Add a new kernel feature to enable the btrfs support

[Bruce Ashfield]

On 11-09-13 4:17 PM, Ashfield, Bruce wrote:

It's there. Have a look in the cfg Sabourin


Ech. This just looped around now after a few days delay. Sorry
about the garbled message .. "sabourin" looked like "subdir"
on my phone when I sent this.

Bruce



Bruce

- Original Message -
From: Kamble, Nitin A [mailto:nitin.a.kam...@intel.com]
Sent: Tuesday, September 13, 2011 01:16 PM
To: Ashfield, Bruce
Cc: yocto@yoctoproject.org
Subject: RE: [yocto] [PATCH 1/1] btrfs: Add a new kernel feature to enable the  
btrfs support

Hi Bruce,
   I am seeing that the patch is still not part of the Linux-yocto-3.0 
repository. Is there any reason it is being hold?

Thanks,
Nitin



-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, September 06, 2011 1:30 PM
To: Kamble, Nitin A
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [PATCH 1/1] btrfs: Add a new kernel feature to
enable the btrfs support

On 11-09-06 03:56 PM, nitin.a.kam...@intel.com wrote:

From: Nitin A Kamble


Looks good. If we are merging this as config only, I've been
putting them in meta/cfg/kernel-cache/cfg/

So I relocated this configuration to that directory. I'll have
it pushed out in the next day or so (I'm getting on a plane
shortly).

Bruce



Signed-off-by: Nitin A Kamble
---
   meta/cfg/kernel-cache/features/btrfs/btrfs.cfg |1 +
   meta/cfg/kernel-cache/features/btrfs/btrfs.scc |1 +
   2 files changed, 2 insertions(+), 0 deletions(-)
   create mode 100644 meta/cfg/kernel-cache/features/btrfs/btrfs.cfg
   create mode 100644 meta/cfg/kernel-cache/features/btrfs/btrfs.scc

diff --git a/meta/cfg/kernel-cache/features/btrfs/btrfs.cfg

b/meta/cfg/kernel-cache/features/btrfs/btrfs.cfg

new file mode 100644
index 000..605c183
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/btrfs/btrfs.cfg
@@ -0,0 +1 @@
+CONFIG_BTRFS_FS=y
diff --git a/meta/cfg/kernel-cache/features/btrfs/btrfs.scc

b/meta/cfg/kernel-cache/features/btrfs/btrfs.scc

new file mode 100644
index 000..cf18a2e
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/btrfs/btrfs.scc
@@ -0,0 +1 @@
+kconf non-hardware btrfs.cfg


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


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

Re: [yocto] [PATCH 1/1][KERNEL] meta: add blktrace feature

[Bruce Ashfield]

On 11-09-18 11:34 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

Add a 'blktrace feature' that turns on kernel support for blktrace, a
block I/O tracing tool.  Added to 'standard' alongside similar tracing
tool config.


Ack'd. I've merged this to the 3.0 tree, and the -dev tree so it will
automatically appear in future trees.

I'll send a pull request for this on Monday.

Bruce



Signed-off-by: Tom Zanussi
---
  .../kernel-cache/features/blktrace/blktrace.cfg|1 +
  .../kernel-cache/features/blktrace/blktrace.scc|1 +
  meta/cfg/kernel-cache/ktypes/standard/standard.scc |3 +++
  3 files changed, 5 insertions(+), 0 deletions(-)
  create mode 100644 meta/cfg/kernel-cache/features/blktrace/blktrace.cfg
  create mode 100644 meta/cfg/kernel-cache/features/blktrace/blktrace.scc

diff --git a/meta/cfg/kernel-cache/features/blktrace/blktrace.cfg 
b/meta/cfg/kernel-cache/features/blktrace/blktrace.cfg
new file mode 100644
index 000..3e61f2b
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/blktrace/blktrace.cfg
@@ -0,0 +1 @@
+CONFIG_BLK_DEV_IO_TRACE=y
diff --git a/meta/cfg/kernel-cache/features/blktrace/blktrace.scc 
b/meta/cfg/kernel-cache/features/blktrace/blktrace.scc
new file mode 100644
index 000..945714b
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/blktrace/blktrace.scc
@@ -0,0 +1 @@
+kconf non-hardware blktrace.cfg
diff --git a/meta/cfg/kernel-cache/ktypes/standard/standard.scc 
b/meta/cfg/kernel-cache/ktypes/standard/standard.scc
index b4e22d0..c8654cc 100644
--- a/meta/cfg/kernel-cache/ktypes/standard/standard.scc
+++ b/meta/cfg/kernel-cache/ktypes/standard/standard.scc
@@ -14,6 +14,9 @@ tag kgdb

  include features/lttng/lttng.scc

+include features/blktrace/blktrace.scc
+tag blktrace
+
  include features/systemtap/systemtap.scc
  tag systemtap



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

Re: [yocto] why the version of "linux-libc-headers-yocto_git" stay on 2.6.37 ?

[Bruce Ashfield]

On 11-09-21 02:01 AM, Ni Qingliang wrote:

the linux-yocto was updated to 3.0.4, but why linux-libc-headers still
2.6.37?


They should match. In the past Khem has done the update on the
header packages, since there are nearly as many toolchain issues
with the headers as with the kernel.

I thought Khem was down as the maintainer for the libc-headers
package, but in my coffee deprived state I can't find evidence
of that.

I can bump the package, unless Khem wants to, or has different
plans.

Cheers,

Bruce






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

Re: [yocto] [PATCH 00/16][KERNEL] meta-intel: emenlow 3.0 kernel changes

[Bruce Ashfield]

On 11-09-21 4:33 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

Please pull into linux-yocto-3.0/yocto/standard/emenlow-3.0.


merged and tracked for future updates. There's no SRCREVs for me to
update for this one, so you can take care of the meta-intel layer
SRCREV bump.

Cheers,

Bruce



Pull URL: git://git.pokylinux.org/linux-yocto-2.6.37-contrib
   Branch: tzanussi/yocto/standard/emenlow-3.0
   Browse: 
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/yocto/standard/emenlow-3.0

Tom Zanussi (16):
   drm: add the base source of the Poulsbo (psb) 2D X11 driver
   drm-psb: remove the package Makefile and replace it with the kernel
 Makefile
   drm: apply psb-kernel-source package's build.patch
   drm: intel_ldvs.c: add missing arg to backlight_device_register()
 call
   emenlow: switch to psb
   drm: Fix psb ioctl assignment
   drm-psb: remove BKL remnants
   drm-psb: update spinlock initializers
   drm-psb: remove call to agp_flush_chipset
   drm-psb: remove includes of nonexistent i2c-id.h
   drm-psb: remove assigment to deprecated i2c_adapter.id
   drm-psb: use console_lock/unlock()
   drm-psb: add DRM_UNLOCKED flag
   drm-psb: mark unlocked ioctls
   drm-psb: initialize backlight type
   drm-psb: fix ioremap calls

  drivers/gpu/Makefile   |2 +-
  drivers/gpu/drm-psb/Config.in  |   17 +
  drivers/gpu/drm-psb/Doxyfile   | 1161 +++
  drivers/gpu/drm-psb/GPLv2_License.txt  |  341 +
  drivers/gpu/drm-psb/Kconfig|  103 +
  drivers/gpu/drm-psb/Makefile   |   76 +
  drivers/gpu/drm-psb/Module.symvers |  339 +
  drivers/gpu/drm-psb/README.drm |   25 +
  drivers/gpu/drm-psb/ati_pcigart.c  |  411 +
  drivers/gpu/drm-psb/create_linux_pci_lists.sh  |   40 +
  drivers/gpu/drm-psb/debian/changelog   |   82 +
  drivers/gpu/drm-psb/debian/compat  |1 +
  drivers/gpu/drm-psb/debian/control |   16 +
  drivers/gpu/drm-psb/debian/copyright   |   53 +
  drivers/gpu/drm-psb/debian/dirs|1 +
  drivers/gpu/drm-psb/debian/dkms.conf.in|   10 +
  drivers/gpu/drm-psb/debian/patches/00list  |   16 +
  .../gpu/drm-psb/debian/patches/01_2.6.32.dpatch|   43 +
  .../drm-psb/debian/patches/02_agp_memory.dpatch|   40 +
  drivers/gpu/drm-psb/debian/patches/03_devt.dpatch  |   20 +
  .../gpu/drm-psb/debian/patches/04_drmpsb.dpatch|   38 +
  .../drm-psb/debian/patches/05_edid-crash.dpatch|   19 +
  .../drm-psb/debian/patches/06_i2c-intelfb.dpatch   |   20 +
  .../drm-psb/debian/patches/07_current_euid.dpatch  |   20 +
  .../gpu/drm-psb/debian/patches/08_irqreturn.dpatch |   23 +
  .../drm-psb/debian/patches/10_change_prefix.dpatch |10351 
  .../debian/patches/11_psb-Declare-firmware.dpatch  |   34 +
  ...sking-for-debug-is-an-error-I-want-to-be.dpatch |   35 +
  .../debian/patches/13_psb-Fix-framebuffer.dpatch   |   94 +
  drivers/gpu/drm-psb/debian/patches/2.6.34.dpatch   |   26 +
  .../gpu/drm-psb/debian/patches/acpi-video.dpatch   |   28 +
  .../gpu/drm-psb/debian/patches/rt-kernel.dpatch|   67 +
  drivers/gpu/drm-psb/debian/patches/use_udev.dpatch |   36 +
  drivers/gpu/drm-psb/debian/postinst|   74 +
  drivers/gpu/drm-psb/debian/postrm  |   33 +
  drivers/gpu/drm-psb/debian/prerm   |   28 +
  drivers/gpu/drm-psb/debian/psb-kernel-headers.dirs |1 +
  .../gpu/drm-psb/debian/psb-kernel-headers.install  |1 +
  .../gpu/drm-psb/debian/psb-kernel-headers.postrm   |   15 +
  .../gpu/drm-psb/debian/psb-kernel-headers.preinst  |   18 +
  drivers/gpu/drm-psb/debian/rules   |   39 +
  drivers/gpu/drm-psb/drm.h  | 1192 +++
  drivers/gpu/drm-psb/drmP.h | 1334 +++
  drivers/gpu/drm-psb/drm_agpsupport.c   |  651 ++
  drivers/gpu/drm-psb/drm_auth.c |  189 +
  drivers/gpu/drm-psb/drm_bo.c   | 2668 +
  drivers/gpu/drm-psb/drm_bo_lock.c  |  189 +
  drivers/gpu/drm-psb/drm_bo_move.c  |  597 ++
  drivers/gpu/drm-psb/drm_bufs.c | 1609 +++
  drivers/gpu/drm-psb/drm_compat.c   |  778 ++
  drivers/gpu/drm-psb/drm_compat.h   |  383 +
  drivers/gpu/drm-psb/drm_context.c  |  472 +
  drivers/gpu/drm-psb/drm_core.h |   35 +
  drivers/gpu/drm-psb/drm_crtc.c | 2169 
  drivers/gpu/drm-psb/drm_crtc.h |  592 ++
  drivers/gpu/drm-psb/drm_dma.c  |  179 +
  drivers/gpu/drm-psb/drm_drawable.c |  192 +
  drivers/gpu/drm-psb/drm_drv.c  |  701 ++
  drivers/gpu/drm-psb/drm_edid.c |  520 +
  driver

Re: [yocto] preempt-rt kernel shutdown now command does not work

[Bruce Ashfield]

On 11-09-29 10:40 PM, Darren Hart wrote:

On 09/29/2011 07:32 PM, Bodke, Kishore K wrote:

Hi Darren,

For the non-rt "shutdown now" works perfectly fine. For the rt
kernel, after the command is issued, it tries to halt the system and
hangs there  forever after the connection to the X server is lost.


Sounds like a legitimate bug. It works in qemux86 with -rt. I'll be able
to test an rt image on a meta-intel board in the morning. In the mean
time, please open a bug and let us know how critical you feel it is.


It's also worth trying the board booted UP versus SMP. We've seen
this in the past with kstop and thread migration interacting badly
on -rt. Forcing them to cpu0 on shutdown fixed those problems.

Bruce





Thanks,

--
Darren



Thanks Kishore.

-Original Message- From: Hart, Darren Sent: Thursday,
September 29, 2011 6:44 PM To: Bodke, Kishore K Cc:
yocto@yoctoproject.org Subject: Re: preempt-rt kernel shutdown now
command does not work

On 09/29/2011 05:54 PM, Bodke, Kishore K wrote:

Hi,

"shutdown -h now" command is not working on core-image-sato image
with preempt-rt kernel 3.0.4  on Romley and crystal forest BSP

I get Warning**: could not initialize ACPI battery. Xinit:
connection to X server lost. xinit: uexpected signal 15


Hi Kishore,


I don't know that I've tried that specific command.

I see the unexpected signal message when shutting down the qemux86
sato image (non-rt) with that or the halt command, but it does shut
all the way down. In your case does the system continue to be
responsive after issuing the command?







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

Re: [yocto] [PATCH 1/5][KERNEL] features/drm-psb: add related config options

[Bruce Ashfield]

On 11-09-29 04:17 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

This allows us to move them out of the bsp config.


Good cleanup.

Bruce



Signed-off-by: Tom Zanussi
---
  meta/cfg/kernel-cache/features/drm-psb/drm-psb.cfg |   13 +
  1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/meta/cfg/kernel-cache/features/drm-psb/drm-psb.cfg 
b/meta/cfg/kernel-cache/features/drm-psb/drm-psb.cfg
index cdd805b..ea7cbfc 100644
--- a/meta/cfg/kernel-cache/features/drm-psb/drm-psb.cfg
+++ b/meta/cfg/kernel-cache/features/drm-psb/drm-psb.cfg
@@ -1,2 +1,15 @@
  CONFIG_DRM=y
  CONFIG_DRM_PSB=m
+
+CONFIG_I2C=y
+CONFIG_VIDEO_V4L2=y
+CONFIG_VIDEO_IVTV=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_VIDEO_CAPTURE_DRIVERS=y
+CONFIG_VIDEO_DEV=y
+CONFIG_VIDEO_V4L2_COMMON=y
+CONFIG_I2C_ALGOBIT=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_VIDEO_FB_IVTV=y


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

Re: [yocto] [PATCH 2/5][KERNEL] meta: add vesafb feature

[Bruce Ashfield]

On 11-09-29 04:17 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

Add a 'vesafb feature' that adds basic vesa framebuffer support.


This one is quite useful. I've seen a similar set of options
collected in other kernels and it has come in handy.

Bruce



Signed-off-by: Tom Zanussi
---
  .../kernel-cache/features/framebuffer/vesafb.cfg   |8 
  .../kernel-cache/features/framebuffer/vesafb.scc   |1 +
  2 files changed, 9 insertions(+), 0 deletions(-)
  create mode 100644 meta/cfg/kernel-cache/features/framebuffer/vesafb.cfg
  create mode 100644 meta/cfg/kernel-cache/features/framebuffer/vesafb.scc

diff --git a/meta/cfg/kernel-cache/features/framebuffer/vesafb.cfg 
b/meta/cfg/kernel-cache/features/framebuffer/vesafb.cfg
new file mode 100644
index 000..9c7f35d
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/framebuffer/vesafb.cfg
@@ -0,0 +1,8 @@
+CONFIG_FB=y
+CONFIG_FB_VESA=y
+CONFIG_FB_BOOT_VESA_SUPPORT=y
+CONFIG_FB_MODE_HELPERS=y
+CONFIG_FB_CFB_COPYAREA=y
+CONFIG_FB_CFB_IMAGEBLIT=y
+CONFIG_FB_CFB_FILLRECT=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
diff --git a/meta/cfg/kernel-cache/features/framebuffer/vesafb.scc 
b/meta/cfg/kernel-cache/features/framebuffer/vesafb.scc
new file mode 100644
index 000..c113097
--- /dev/null
+++ b/meta/cfg/kernel-cache/features/framebuffer/vesafb.scc
@@ -0,0 +1 @@
+kconf non-hardware vesafb.cfg


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

Re: [yocto] [PATCH 3/5][KERNEL] crownbay: cleanup bsp config

[Bruce Ashfield]

On 11-09-29 04:17 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

Remove unnecessary options or options already defined in base configs.


Ack'd. Looks like a nice streamlining.

Bruce



Signed-off-by: Tom Zanussi
---
  meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg |   34 +-
  meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc |5 ++-
  2 files changed, 11 insertions(+), 28 deletions(-)

diff --git a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg 
b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg
index 5daa65b..76a48eb 100644
--- a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg
+++ b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg
@@ -27,6 +27,12 @@ CONFIG_SOUND=y
  CONFIG_SND=y
  CONFIG_SND_HDA_INTEL=y
  CONFIG_SATA_AHCI=y
+CONFIG_AGP=y
+CONFIG_PM=y
+CONFIG_ACPI=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_INPUT=y

  # Make sure these are on, otherwise the bootup won't be fun
  CONFIG_EXT3_FS=y
@@ -37,33 +43,9 @@ CONFIG_SHMEM=y
  CONFIG_TMPFS=y
  CONFIG_PACKET=y

-# These are needed for the Poulsbo kernel modules
-CONFIG_I2C=y
-CONFIG_AGP=y
-CONFIG_VFAT_FS=y
-CONFIG_PM=y
-CONFIG_ACPI=y
-CONFIG_FB=y
-CONFIG_BACKLIGHT_LCD_SUPPORT=y
-CONFIG_BACKLIGHT_CLASS_DEVICE=y
-CONFIG_INPUT=y
-CONFIG_VIDEO_V4L2=y
-CONFIG_VIDEO_IVTV=y
-CONFIG_MEDIA_SUPPORT=y
-CONFIG_VIDEO_CAPTURE_DRIVERS=y
-CONFIG_VIDEO_DEV=y
-CONFIG_VIDEO_V4L2_COMMON=y
-CONFIG_I2C_ALGOBIT=y
-CONFIG_FB_CFB_COPYAREA=y
-CONFIG_FB_CFB_IMAGEBLIT=y
-CONFIG_FB_CFB_FILLRECT=y
-CONFIG_VIDEO_FB_IVTV=y
-
  # Needed for booting (and using) USB memory sticks
-CONFIG_USB_STORAGE=y
-CONFIG_BLK_DEV_RAM=y
  CONFIG_BLK_DEV_LOOP=y
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_RD_GZIP=y
  CONFIG_NLS_CODEPAGE_437=y
  CONFIG_NLS_ISO8859_1=y
+
+CONFIG_RD_GZIP=y
diff --git a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc 
b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc
index 63b7ad6..3114cbc 100644
--- a/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc
+++ b/meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc
@@ -8,10 +8,11 @@ include features/intel-e1/intel-e1.scc
  include features/drm-emgd/drm-emgd.scc
  include features/dmaengine/dmaengine.scc
  include features/serial/8250.scc
+include features/hpet/hpet.scc
+include features/framebuffer/vesafb.scc
+include cfg/usb-mass-storage.scc

  include features/logbuf/size-normal.scc

  include features/latencytop/latencytop.scc
  include features/profiling/profiling.scc
-
-include features/hpet/hpet.scc


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

Re: [yocto] [PATCH 0/5][KERNEL] some meta-intel bsp cleanup

[Bruce Ashfield]

On 11-09-29 04:17 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

This patchset is another step in some cleanup I'm doing for
the meta-intel bsps, basically removing unneeded or redundant
options and abstracting out useful features, in this case a
new vesafb feature used in this patchset by crownbay, emenlow,
and jasperforest.

Please pull into linux-yocto-3.0-(next).


All good stuff. I'll stage this to be in 3.0 for post 1.1
updates, and in the -dev kernel for the next kernel version
that is pushed out.

Bruce



Pull URL: git://git.pokylinux.org/linux-yocto-2.6.37-contrib
   Branch: tzanussi/bsp-cleanup-2
   Browse: 
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/bsp-cleanup-2

Thanks,

Tom

Tom Zanussi (5):
   features/drm-psb: add related config options
   meta: add vesafb feature
   crownbay: cleanup bsp config
   emenlow: cleanup bsp config
   jasperforest: cleanup bsp config

  meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg|   34 --
  meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc|5 ++-
  meta/cfg/kernel-cache/bsp/emenlow/emenlow.cfg  |   35 +--
  meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc  |2 +
  .../kernel-cache/bsp/jasperforest/jasperforest.cfg |7 +---
  .../kernel-cache/bsp/jasperforest/jasperforest.scc |2 +
  meta/cfg/kernel-cache/features/drm-psb/drm-psb.cfg |   13 +++
  .../kernel-cache/features/framebuffer/vesafb.cfg   |8 
  .../kernel-cache/features/framebuffer/vesafb.scc   |1 +
  9 files changed, 48 insertions(+), 59 deletions(-)
  create mode 100644 meta/cfg/kernel-cache/features/framebuffer/vesafb.cfg
  create mode 100644 meta/cfg/kernel-cache/features/framebuffer/vesafb.scc



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

Re: [yocto] [PATCH 0/4][KERNEL] enable booting from iso

[Bruce Ashfield]

On 11-10-04 11:40 AM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

A few of the 32-bit meta-intel BSPs need the boot-live config turned on
in order boot from iso images.  This patchset does that for crownbay,
emenlow, fishriver, and fri2.

Tested on crownbay.


merged and out in the kernel repo. SRCREV update is arriving
shortly to an inbox near you.

Bruce



Please pull into linux-yocto-3.0/meta.

Pull URL: git://git.pokylinux.org/linux-yocto-2.6.37-contrib
   Branch: tzanussi/isoboot-fixes-2
   Browse: 
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/isoboot-fixes-2

Tom Zanussi (4):
   meta/crownbay: enable booting from iso
   meta/emenlow: enable booting from iso
   meta/fishriver: enable booting from iso
   meta/fri2: enable booting from iso

  meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg   |3 +++
  meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc   |1 +
  meta/cfg/kernel-cache/bsp/emenlow/emenlow.cfg |3 +++
  meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc |1 +
  meta/cfg/kernel-cache/bsp/fishriver/fishriver.cfg |3 +++
  meta/cfg/kernel-cache/bsp/fishriver/fishriver.scc |1 +
  meta/cfg/kernel-cache/bsp/fri2/fri2.cfg   |3 +++
  meta/cfg/kernel-cache/bsp/fri2/fri2.scc   |1 +
  8 files changed, 16 insertions(+), 0 deletions(-)

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


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

Re: [yocto] [PATCH 0/8][KERNEL] some meta-intel bsp cleanup, v4

[Bruce Ashfield]

On Sun, Oct 9, 2011 at 11:34 PM,   wrote:
> From: Tom Zanussi 
>
> This patchset is another step in some cleanup I'm doing for
> the meta-intel bsps, basically removing unneeded or redundant
> options and abstracting out useful features, in this case a
> new vesafb feature used in this patchset by crownbay, emenlow,
> and jasperforest.
>
> This patchset doesn't change any of the previous patches - I'm
> just resending them all to avoid confusion since I accidentally
> named the v2 branch v3.  So this patchset keeps everything
> up-to-date and supersedes the previous "v2" patchset.

Perfect. I just tossed out the v2 I had staged and will push this out
later today once
the Canadian thanksgiving festivities subside!

Bruce

>
> v2: rebased on top of intervening changes
> v3: misnamed
> v4: added fishriver, sugarbay, fri2
>
> Please pull into linux-yocto-3.0.
>
> Pull URL: git://git.pokylinux.org/linux-yocto-2.6.37-contrib
>  Branch: tzanussi/bsp-cleanup-v4
>  Browse: 
> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/bsp-cleanup-v4
>
> Thanks,
>
> Tom
>
> Tom Zanussi (8):
>  features/drm-psb: add related config options
>  meta: add vesafb feature
>  crownbay: cleanup bsp config
>  emenlow: cleanup bsp config
>  jasperforest: cleanup bsp config
>  fishriver: cleanup bsp config
>  sugarbay: cleanup bsp config
>  fri2: cleanup bsp config
>
>  meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg    |   34 --
>  meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc    |    5 ++-
>  meta/cfg/kernel-cache/bsp/emenlow/emenlow.cfg      |   35 +--
>  meta/cfg/kernel-cache/bsp/emenlow/emenlow.scc      |    2 +
>  meta/cfg/kernel-cache/bsp/fishriver/fishriver.cfg  |   34 --
>  meta/cfg/kernel-cache/bsp/fishriver/fishriver.scc  |    2 +
>  meta/cfg/kernel-cache/bsp/fri2/fri2.cfg            |   34 --
>  meta/cfg/kernel-cache/bsp/fri2/fri2.scc            |    2 +
>  .../kernel-cache/bsp/jasperforest/jasperforest.cfg |    7 +---
>  .../kernel-cache/bsp/jasperforest/jasperforest.scc |    2 +
>  meta/cfg/kernel-cache/bsp/sugarbay/sugarbay.cfg    |   22 +---
>  meta/cfg/kernel-cache/bsp/sugarbay/sugarbay.scc    |    1 +
>  meta/cfg/kernel-cache/features/drm-psb/drm-psb.cfg |   13 +++
>  .../kernel-cache/features/framebuffer/vesafb.cfg   |    8 
>  .../kernel-cache/features/framebuffer/vesafb.scc   |    1 +
>  15 files changed, 71 insertions(+), 131 deletions(-)
>  create mode 100644 meta/cfg/kernel-cache/features/framebuffer/vesafb.cfg
>  create mode 100644 meta/cfg/kernel-cache/features/framebuffer/vesafb.scc
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 0/4][KERNEL] more bsp cleanup and new power/intel feature

[Bruce Ashfield]

On 11-10-25 03:17 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

This patchset adds a new power/intel feature containing power-related
config items for intel bsps and initially makes sugarbay and crownbay
use it.

It also removes the igb feature from common-pc-64, which shouldn't
be there and was responsible for Yocto bug #1188.

Fixes [YOCTO #1188]

Please pull into linux-yocto-3.0 and linux-yocto-dev.


Looks good. Do you agree that this would be part
of any 1.1 point release as well, or is this purely a
1.2/cleanup activity ? If it's the latter, I need to wait
for the 1.1 sustaining kernel to be created.

Bruce



Pull URL: git://git.pokylinux.org/linux-yocto-2.6.37-contrib
   Branch: tzanussi/bsp-cleanup2-v0
   Browse: 
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/bsp-cleanup2-v0

Tom Zanussi (4):
   meta: add power feature
   meta/sugarbay: use power/intel feature
   meta/crownbay: use power/intel feature
   meta/common-pc-64: remove igb

  .../kernel-cache/bsp/common-pc-64/common-pc-64.scc |1 -
  meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc|1 +
  meta/cfg/kernel-cache/bsp/sugarbay/sugarbay.scc|1 +
  meta/cfg/kernel-cache/features/power/intel.cfg |   28 
  meta/cfg/kernel-cache/features/power/intel.scc |1 +
  5 files changed, 31 insertions(+), 1 deletions(-)
  create mode 100644 meta/cfg/kernel-cache/features/power/intel.cfg
  create mode 100644 meta/cfg/kernel-cache/features/power/intel.scc



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

Re: [yocto] Building for pandaboard

[Bruce Ashfield]

On 11-10-27 8:45 PM, Brian Park wrote:

Hi,
I'm interested in using Yocto to build linux for PandaBoard. It seems
there are already patches some where that I can use to build for panda,
as I found some discussions mentioning PandaBoard patch in the archive.
But I could not apply it. I'd appreciate some pointers on how to find
and apply the right patch.

Just trying to apply
http://article.gmane.org/gmane.linux.embedded.yocto.general/2037/match=pandaboard
as a patch using "git am" command gave the following error. I'm using
release 1.1 Edison.

briansp@LinuxMint11 ~/poky $ git am < ~/Documents/pandaboard.patch
previous rebase directory /home/briansp/poky/.git/rebase-apply still
exists but mbox given.

I'm new to developing for linux and yocto. So, any help would be
appreciated.


Those same patches are merged into the 2.6.37 kernel tree here:

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37/log/?h=yocto/standard/pandaboard

So if you do want to use the linux-yocto kernel, you could set
your preferred kernel version to 2.6.37 and you'd get that
kernel and branch for the board.

But like anything, nothing is completely simple, the support in
the 2.6.37 tree was contributed in an effort to add some more board
support to a yocto tested/standardized kernel. There are multiple
sources for pandaboard support, with different functionality (i.e. 
deeper, different kernel version, etc), different integration and

different goals. i.e. angstrom and meta-texasinstruments.

To use the 2.6.37 support you'd need a configuration of the machine and
a meta layer defining the userspace. There was a prototype one that
floated around, but it was being re-worked to use layer tooling and not
duplicate effort that is in other layers already.

If you like, I can locate that layer and send it along, or you can
try out the other references I mentioned (others may have better /
more detailed information).

Cheers,

Bruce



Thank you

Brian



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


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

Re: [yocto] Building for pandaboard

[Bruce Ashfield]

On 11-10-28 1:06 PM, Brian Park wrote:

Thanks for the info.
As I'm very new to Yocto, I'd not know how to create local.conf to build
for panda, even knowing that the kernel will support pandaboard. How
would I go about configuring Yocto to build for panda? If you can point
me to some documentation showing how to do it, I'd appreciate it.

I'm just learning yocto, in my spare time, and just went through the
quick start guide to build for x86qemu image and skimmed through the
development manual. But I'm not too sure how to go about configuring for
pandaboard. I figured, I can build for beagle board and then modify
config to make it work for panda. However, I'm having build issue when
trying to build for beagle board.


That would likely work for userspace (minus the build error you
mentioned) with the appropriate config changes. But for the kernel,
there is a different set of patches for board support, so you do
need to pick the right layer and preferred kernel.



If there is already an existing pandaboard config, I'd like to try it.


There is one floating around, I'll locate the latest tgz and you
can try it out in the yocto context (I say yocto, since as I've
mentioned there are other oe based configs and layers that can be
used for panda support as well).

Cheers,

Bruce



Thank you.

Brian

On Thu, Oct 27, 2011 at 9:51 PM, Bruce Ashfield
mailto:bruce.ashfi...@windriver.com>> wrote:

On 11-10-27 8:45 PM, Brian Park wrote:

Hi,
I'm interested in using Yocto to build linux for PandaBoard. It
seems
there are already patches some where that I can use to build for
panda,
as I found some discussions mentioning PandaBoard patch in the
archive.
But I could not apply it. I'd appreciate some pointers on how to
find
and apply the right patch.

Just trying to apply

http://article.gmane.org/__gmane.linux.embedded.yocto.__general/2037/match=pandaboard

<http://article.gmane.org/gmane.linux.embedded.yocto.general/2037/match=pandaboard>
as a patch using "git am" command gave the following error. I'm
using
release 1.1 Edison.

briansp@LinuxMint11 ~/poky $ git am < ~/Documents/pandaboard.patch
previous rebase directory /home/briansp/poky/.git/__rebase-apply
still
exists but mbox given.

I'm new to developing for linux and yocto. So, any help would be
appreciated.


Those same patches are merged into the 2.6.37 kernel tree here:


http://git.yoctoproject.org/__cgit/cgit.cgi/linux-yocto-2.6.__37/log/?h=yocto/standard/__pandaboard

<http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37/log/?h=yocto/standard/pandaboard>

So if you do want to use the linux-yocto kernel, you could set
your preferred kernel version to 2.6.37 and you'd get that
kernel and branch for the board.

But like anything, nothing is completely simple, the support in
the 2.6.37 tree was contributed in an effort to add some more board
support to a yocto tested/standardized kernel. There are multiple
sources for pandaboard support, with different functionality (i.e.
deeper, different kernel version, etc), different integration and
different goals. i.e. angstrom and meta-texasinstruments.

To use the 2.6.37 support you'd need a configuration of the machine and
a meta layer defining the userspace. There was a prototype one that
floated around, but it was being re-worked to use layer tooling and not
duplicate effort that is in other layers already.

If you like, I can locate that layer and send it along, or you can
try out the other references I mentioned (others may have better /
more detailed information).

Cheers,

Bruce


Thank you

Brian



_
yocto mailing list
yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.__org/listinfo/yocto
<https://lists.yoctoproject.org/listinfo/yocto>





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

Re: [yocto] [PATCH 0/4][KERNEL] some more bsp cleanups

[Bruce Ashfield]

On 11-11-07 10:56 AM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

This just finishes up the previous set of meta-intel cleanups.  All
machines were build- and run-tested.

Please pull into linux-yocto-3.0 and linux-yocto-dev.

The following changes since commit 4095bb597a7bcd647856aa35b5fb8637ed7ff975:
   Tom Zanussi (1):
 meta/common-pc-64: remove igb

are available in the git repository at:

   git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git 
tzanussi/bsp-cleanup3
   http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/bsp-cleanup3


These all look good to me, I've grabbed them and will push them
out in the next day or so.

Bruce



Tom Zanussi (4):
   meta/fishriver: use power/intel feature
   meta/fri2: use power/intel feature
   meta/jasperforest: use power/intel feature
   meta/fishriver: enable hpet

  meta/cfg/kernel-cache/bsp/fishriver/fishriver.scc  |2 ++
  meta/cfg/kernel-cache/bsp/fri2/fri2.scc|1 +
  .../kernel-cache/bsp/jasperforest/jasperforest.scc |1 +
  3 files changed, 4 insertions(+), 0 deletions(-)



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

Re: [yocto] [PATCH 0/1] [KERNEL] Add rt support to meta branch for romley.

[Bruce Ashfield]

On 11-11-08 02:22 PM, kishore.k.bo...@intel.com wrote:

From: Kishore Bodke

Hi All,

This is the patch to support rt in the kernel meta branch for romley.

Please pull into linux-yocto-3.0/meta and linux-yocto-dev/meta.


pull into my local repos, I'll have an update for this later today
or early tomorrow.

Bruce




Thanks
Kishore.

The following changes since commit 4095bb597a7bcd647856aa35b5fb8637ed7ff975:

   meta/common-pc-64: remove igb (2011-11-02 16:23:13 -0400)

are available in the git repository at:
   git://git.yoctoproject.org/linux-yocto-2.6.37-contrib kishore/meta-romley
   
http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=kishore/meta-romley

Kishore Bodke (1):
   meta/romley: Add rt support
   Add rt support to the meta branch for romley.

  .../kernel-cache/bsp/romley/romley-preempt-rt.scc  |8 
  1 files changed, 8 insertions(+), 0 deletions(-)
  create mode 100644 meta/cfg/kernel-cache/bsp/romley/romley-preempt-rt.scc



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

Re: [yocto] [PATCH][linux-yocto] mount_root: clarify error messages for when no rootfs found (V2)

[Bruce Ashfield]

On 11-11-15 3:19 PM, Darren Hart wrote:

The following is a modified version the patch at:


Works for me as well, I'll update the variant in the yocto kernel
trees, while we wait to see if anyone upstream has any interest.

Bruce



meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG
so that even using loglevel=1 at boot, the end user will see:

[0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[0.223457] User configuration error - no valid root filesystem found
[0.230057] Kernel panic - not syncing: Invalid configuration from end user 
preg
[0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[0.245691] Call Trace:
[0.248218]  [] ? 0xc04eddbc
[0.252071]  [] ? 0xc05549ad
[0.255928]  [] ? 0xc05549fa
[0.259790]  [] ? 0xc0554623
[0.263650]  [] ? 0xc0554b1c
[0.267497]  [] ? 0xc055472a
[0.271344]  [] ? 0xc04f0df6

Instead of just:

[0.230057] Kernel panic - not syncing: Invalid configuration from end user 
preg
...

Which is arguably no better than what this patch originally attempted to 
address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' 
tree.

Thanks,

Darren

--

To an end user who doesn't really know linux that well, a
message like:

   Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)

may just look like cryptic computer speak indicating some
deep and complex problem, instead of the reality that they
have a simple local configuration problem.  Ideally it would
be nice to not use the misleading "panic" at all, but since
various panic notifiers are historically expecting to be
called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of
any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

Signed-off-by: Paul Gortmaker
Signed-off-by: Darren Hart
---
  init/do_mounts.c |8 ++--
  1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/init/do_mounts.c b/init/do_mounts.c
index bb008d0..d24b8c7 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -270,7 +270,9 @@ retry:
printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
   "explicit textual name for \"root=\" boot option.\n");
  #endif
-   panic("VFS: Unable to mount root fs on %s", b);
+   printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+   printk(KERN_EMERG "User configuration error - no valid root 
filesystem found\n");
+   panic("Invalid configuration from end user prevents 
continuing");
}

printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
  #ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
  #endif
-   panic("VFS: Unable to mount root fs on %s", b);
+   printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+   printk(KERN_EMERG "User configuration error - no valid root filesystem 
found\n");
+   panic("Invalid configuration from end user prevents continuing");
  out:
putname(fs_names);
  }


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

Re: [yocto] [PATCH][linux-yocto] mount_root: clarify error messages for when no rootfs found (V2)

[Bruce Ashfield]

On 11-11-16 10:45 AM, Darren Hart wrote:



On 11/15/2011 09:36 PM, Bruce Ashfield wrote:

On 11-11-15 3:19 PM, Darren Hart wrote:

The following is a modified version the patch at:


Works for me as well, I'll update the variant in the yocto kernel
trees, while we wait to see if anyone upstream has any interest.


I we can't get it upstream, I'd argue we drop this. As Paul said, it is
cosmetic. When people see this error, the only place they'll find help


I have no plans to drop this. It's a value add, and simply
because not everyone wants it, doesn't mean we let it go.

We can carry it and try again if it doesn't make it upstream.


is here on the yocto list. They should be able to debug the kernel with
all the Linux Kernel resources out there. Having custom kernel messages
for Yocto prevents that.


I disagree.

Bruce



--
Darren



Bruce



meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG
so that even using loglevel=1 at boot, the end user will see:

[0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[0.223457] User configuration error - no valid root filesystem found
[0.230057] Kernel panic - not syncing: Invalid configuration from end user 
preg
[0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[0.245691] Call Trace:
[0.248218]  [] ? 0xc04eddbc
[0.252071]  [] ? 0xc05549ad
[0.255928]  [] ? 0xc05549fa
[0.259790]  [] ? 0xc0554623
[0.263650]  [] ? 0xc0554b1c
[0.267497]  [] ? 0xc055472a
[0.271344]  [] ? 0xc04f0df6

Instead of just:

[0.230057] Kernel panic - not syncing: Invalid configuration from end user 
preg
...

Which is arguably no better than what this patch originally attempted to 
address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' 
tree.

Thanks,

Darren

--

To an end user who doesn't really know linux that well, a
message like:

Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)

may just look like cryptic computer speak indicating some
deep and complex problem, instead of the reality that they
have a simple local configuration problem.  Ideally it would
be nice to not use the misleading "panic" at all, but since
various panic notifiers are historically expecting to be
called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of
any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

Signed-off-by: Paul Gortmaker
Signed-off-by: Darren Hart
---
   init/do_mounts.c |8 ++--
   1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/init/do_mounts.c b/init/do_mounts.c
index bb008d0..d24b8c7 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -270,7 +270,9 @@ retry:
printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
   "explicit textual name for \"root=\" boot option.\n");
   #endif
-   panic("VFS: Unable to mount root fs on %s", b);
+   printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+   printk(KERN_EMERG "User configuration error - no valid root 
filesystem found\n");
+   panic("Invalid configuration from end user prevents 
continuing");
}

printk("List of all partitions:\n");
@@ -282,7 +284,9 @@ retry:
   #ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
   #endif
-   panic("VFS: Unable to mount root fs on %s", b);
+   printk(KERN_EMERG "VFS: Unable to mount root fs on %s\n", b);
+   printk(KERN_EMERG "User configuration error - no valid root filesystem 
found\n");
+   panic("Invalid configuration from end user prevents continuing");
   out:
putname(fs_names);
   }






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

Re: [yocto] [PATCH][linux-yocto] mount_root: clarify error messages for when no rootfs found (V2)

[Bruce Ashfield]

On 11-11-16 11:00 AM, Darren Hart wrote:



On 11/16/2011 07:51 AM, Bruce Ashfield wrote:

On 11-11-16 10:45 AM, Darren Hart wrote:



On 11/15/2011 09:36 PM, Bruce Ashfield wrote:

On 11-11-15 3:19 PM, Darren Hart wrote:

The following is a modified version the patch at:


Works for me as well, I'll update the variant in the yocto kernel
trees, while we wait to see if anyone upstream has any interest.


I we can't get it upstream, I'd argue we drop this. As Paul said, it is
cosmetic. When people see this error, the only place they'll find help


I have no plans to drop this. It's a value add, and simply
because not everyone wants it, doesn't mean we let it go.

We can carry it and try again if it doesn't make it upstream.


is here on the yocto list. They should be able to debug the kernel with
all the Linux Kernel resources out there. Having custom kernel messages
for Yocto prevents that.


I disagree.


With which part? That they should be able to use all the available
resources? Or that custom kernel messages restrict where they can get
help? I don't see how you can really argue against either of those...


Sorry for the short reply, I was being pulled away and couldn't
elaborate.

I don't see the two issues as being tied together or at least
not signifcantly. If  two people are debugging a kernel issue, it is
incumbent that they know the trees they are using and to ensure that
they are at least somewhat in sync. The changes aren't hidden in any
way, so it's easy to know what is in play.

It's no different than using a arch/vendor tree versus mainline
or linux-next, or even two different mainline trees where one has
a changed strings. A grep or search will fail, and at that point
we sync on the tree versions and make sure they match.

There's plenty of other bigger issues that a few different
messages coming out of the kernel that can prevent people from
using resources. So I'm not arguing that it isn't a factor, I'm
just saying that it (a custom message) isn't a significant one.

Obviously we want the patch to be upstream, that's a baseline
goal for any change and I understand frustration and losing some
time during debug. But that particular message has been proven
to save lots of time in many other situations, so I wouldn't shoot
myself in the foot by dropping it based solely on it not being
upstream.

I'd modify it to meet comments, make it optional, prepend
[yocto], dropping it would be last resort.

I'm heading AFK again, but will be back later today.

Cheers,

Bruce



--
Darren



Bruce



--
Darren



Bruce



meta/cfg/kernel-cache/patches/boot/mount_root-clarify-error-messages-for-when-no-rootfs.patch

in the linux-yocto-3.0 git repository. This version adds KERN_EMERG
so that even using loglevel=1 at boot, the end user will see:

[0.217462] VFS: Unable to mount root fs on unknown-block(8,2)
[0.223457] User configuration error - no valid root filesystem found
[0.230057] Kernel panic - not syncing: Invalid configuration from end user 
preg
[0.238992] Pid: 1, comm: swapper Not tainted 3.0.4-yocto-standard+ #2
[0.245691] Call Trace:
[0.248218]  [] ? 0xc04eddbc
[0.252071]  [] ? 0xc05549ad
[0.255928]  [] ? 0xc05549fa
[0.259790]  [] ? 0xc0554623
[0.263650]  [] ? 0xc0554b1c
[0.267497]  [] ? 0xc055472a
[0.271344]  [] ? 0xc04f0df6

Instead of just:

[0.230057] Kernel panic - not syncing: Invalid configuration from end user 
preg
...

Which is arguably no better than what this patch originally attempted to 
address.

Paul, has this patch been sent upstream for inclusion? I don't see it in Linus' 
tree.

Thanks,

Darren

--

To an end user who doesn't really know linux that well, a
message like:

 Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)

may just look like cryptic computer speak indicating some
deep and complex problem, instead of the reality that they
have a simple local configuration problem.  Ideally it would
be nice to not use the misleading "panic" at all, but since
various panic notifiers are historically expecting to be
called when there is no valid rootfs, we can't change that.

So instead, this tries to make it 100% clear to folks of
any background that it is an end user configuration issue.

V2: Use KERN_EMERG so the printk context isn't lost when using loglevel

Signed-off-by: Paul Gortmaker
Signed-off-by: Darren Hart
---
init/do_mounts.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/init/do_mounts.c b/init/do_mounts.c
index bb008d0..d24b8c7 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -270,7 +270,9 @@ retry:
printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
   "explicit textual name for \"root=\"

Re: [yocto] Linux kernel recipe template

[Bruce Ashfield]

On 11-11-21 11:01 AM, Ilya Dmitrichenko wrote:

Hello List,

I have had an attempt to build a kernel from the git sources, trying
to checkout the v3.1.1 tag, but it appeared to be more difficult then
I thought. Most of the problem I have had with the yocto-specific
metadata and some of the extra tasks that it adds. What is the
cleanest and compatible way to build a kernel from git or any standard
tree (i.e. 2.6.x or later).


Opinions vary on this point, but if you want to try and use the
yocto kernel tools, add your own meta data and manage the kernel
and follow some of the yocto kernel development workflows .. then
there are compatibility modes and some setup to do what you want.

I also always have a development kernel (currently at 3.2-rc2), if
you need something newer than 3.0.x.

See below for more information.



I can see that the yocto way of building kernel is to provide a commit
ID for each specific architecture and there also these metadata
branches, which don't quite understand yet. I managed to somehow slip
through, but with manual creation of stamp files and manual 'make all
O=../' stage. I don't seem to find any detailed guide,
would be great to just see a template in the tree which do just a
basic build from a given SRC_URI. It would be also nice to have a line
in this template which would demonstrate how to apply a custom base
kernel config too.


I have a korg example in poky-extras/meta-kerne-dev/ 
(git://git.pokylinux.org/poky-extras),

which is intended to show pretty what you were looking for.

I have usecase and documentation requirements for yocto 1.2 for this
example as well, so better references are forthcoming in the not
to distant future.

Cheers,

Bruce



Regards,


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

Re: [yocto] linux-yocto: doesn't maintain patch order from SRC_URI?

[Bruce Ashfield]

On 11-11-29 04:39 PM, Darren Hart wrote:

I'm experimenting with Matt Fleming's EFI_STUB patches. The first 10 patches 
were working fine, but when I try to add the 11th, the do_patch fails. I found 
that it isn't trying to apply the patches in the order listed in the recipe - 
no in any other recognizable pattern for that matter.



It's shell order. You really should just create a .scc file, put IT
on the SRC_URI and list the patches. You'll have no problems after
that.

I do have a fix for this, but can't send it right now due to travel.

You are using the compatibility mode for more than I originally intended
it for. So just dropping a .scc file into place will fix things
up nicely.

Bruce


The recipe contains:

# Add the efi-stub
SRC_URI += 
"file://0001-x86-Add-missing-bzImage-fields-to-struct-setup_heade.patch \
 
file://0002-x86-efi-Make-efi_call_phys_prelog-CONFIG_RELOCATABLE.patch \
 
file://0003-x86-Don-t-use-magic-strings-for-EFI-loader-signature.patch \
 
file://0004-efi.h-Add-struct-definition-for-boot-time-services.patch \
 file://0005-efi.h-Add-efi_image_loaded_t.patch \
 
file://0006-efi.h-Add-allocation-types-for-boottime-allocate_pag.patch \
 file://0007-efi.h-Add-graphics-protocol-guids.patch \
 file://0008-efi.h-Add-boottime-locate_handle-search-types.patch \
 file://0009-efi-Add-EFI-file-I-O-data-types.patch \
 file://0010-x86-efi-EFI-boot-stub-support.patch \
file://0011-x86-efi-Break-up-large-initrd-reads.patch \
 "

do_patch fails with:
Log data follows:
| Deleted branch meta-temp (was 620917d).
| warning: could not find (or was already included): ktypes/yocto.scc
| ./0-standard-yocto-61b5e146f9d113375883df8c51449722.sco: line 14: 
yocto_68b329da9893e34099c7d8ad5cb9c940: command not found
| [INFO] validating against known patches  (standard-yocto-meta)
error: arch/x86/boot/compressed/eboot.c: does not exist in index09 %)
| To force apply this patch, use 'guilt push -f'
| [ERROR] unable to complete push
| pending patches are:
| Patches directory doesn't exist, try guilt-init
| ERROR. could not update git tree
| ERROR: Function 'do_patch' failed (see 
/build/poky/ie/tmp/work/ie_phase1-poky-linux/linux-yocto-ie-3.0.4+git1+d51b0e743599a41a42e119f29f8dfa89854b3b5e_1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r4/temp/log.do_patch.2768
 for further information)

and meta/patches/standard/series contains:

$ cat standard/series
links/scratch/obj/0002-x86-efi-Make-efi_call_phys_prelog-CONFIG_RELOCATABLE.patch
links/scratch/obj/0003-x86-Don-t-use-magic-strings-for-EFI-loader-signature.patch
links/scratch/obj/0004-efi.h-Add-struct-definition-for-boot-time-services.patch
links/scratch/obj/0005-efi.h-Add-efi_image_loaded_t.patch
links/scratch/obj/0011-x86-efi-Break-up-large-initrd-reads.patch

This needs to come after 10.

links/scratch/obj/0007-efi.h-Add-graphics-protocol-guids.patch
links/scratch/obj/0001-x86-Add-missing-bzImage-fields-to-struct-setup_heade.patch
links/scratch/obj/0009-efi-Add-EFI-file-I-O-data-types.patch
links/scratch/obj/0008-efi.h-Add-boottime-locate_handle-search-types.patch
links/scratch/obj/0006-efi.h-Add-allocation-types-for-boottime-allocate_pag.patch
links/scratch/obj/0010-x86-efi-EFI-boot-stub-support.patch





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

Re: [yocto] linux-yocto: doesn't maintain patch order from SRC_URI?

[Bruce Ashfield]

On 11-11-29 07:46 PM, Darren Hart wrote:



On 11/29/2011 03:14 PM, Bruce Ashfield wrote:

On 11-11-29 04:39 PM, Darren Hart wrote:

I'm experimenting with Matt Fleming's EFI_STUB patches. The first 10 patches 
were working fine, but when I try to add the 11th, the do_patch fails. I found 
that it isn't trying to apply the patches in the order listed in the recipe - 
no in any other recognizable pattern for that matter.



It's shell order.


Oh, how is this shell order?


s/shell/modification time order/

There's a find that locates the patches. The order returned by find
is what is returned used to generate an auto-scc file that is then
used to merge with the rest of the infrastructure.

I did a couple of minor changes here, sorting the patch location,
and support for directories of patches. But there's only so far
that I'm going to go for now.

What I'm trying to implement is a mode that the core patch class
will simply dump me a list of patches, that way I don't duplicate any
code, but can feed that into the scripts. I'm not there yet, but am
still working on it, since we can work around this for now, I'll try
and get this right before pushing out any changes.

Cheers,

Bruce



$ ls *patch
0001-x86-Add-missing-bzImage-fields-to-struct-setup_heade.patch
0002-x86-efi-Make-efi_call_phys_prelog-CONFIG_RELOCATABLE.patch
0003-x86-Don-t-use-magic-strings-for-EFI-loader-signature.patch
0004-efi.h-Add-struct-definition-for-boot-time-services.patch
0005-efi.h-Add-efi_image_loaded_t.patch
0006-efi.h-Add-allocation-types-for-boottime-allocate_pag.patch
0007-efi.h-Add-graphics-protocol-guids.patch
0008-efi.h-Add-boottime-locate_handle-search-types.patch
0009-efi-Add-EFI-file-I-O-data-types.patch
0010-x86-efi-EFI-boot-stub-support.patch
0011-x86-efi-Break-up-large-initrd-reads.patch

This is the order I would expect and seems to match shell order...

--
Darren


You really should just create a .scc file, put IT
on the SRC_URI and list the patches. You'll have no problems after
that.

I do have a fix for this, but can't send it right now due to travel.

You are using the compatibility mode for more than I originally intended
it for. So just dropping a .scc file into place will fix things
up nicely.

Bruce


The recipe contains:

# Add the efi-stub
SRC_URI += 
"file://0001-x86-Add-missing-bzImage-fields-to-struct-setup_heade.patch \
  
file://0002-x86-efi-Make-efi_call_phys_prelog-CONFIG_RELOCATABLE.patch \
  
file://0003-x86-Don-t-use-magic-strings-for-EFI-loader-signature.patch \
  
file://0004-efi.h-Add-struct-definition-for-boot-time-services.patch \
  file://0005-efi.h-Add-efi_image_loaded_t.patch \
  
file://0006-efi.h-Add-allocation-types-for-boottime-allocate_pag.patch \
  file://0007-efi.h-Add-graphics-protocol-guids.patch \
  file://0008-efi.h-Add-boottime-locate_handle-search-types.patch \
  file://0009-efi-Add-EFI-file-I-O-data-types.patch \
  file://0010-x86-efi-EFI-boot-stub-support.patch \
file://0011-x86-efi-Break-up-large-initrd-reads.patch \
  "

do_patch fails with:
Log data follows:
| Deleted branch meta-temp (was 620917d).
| warning: could not find (or was already included): ktypes/yocto.scc
| ./0-standard-yocto-61b5e146f9d113375883df8c51449722.sco: line 14: 
yocto_68b329da9893e34099c7d8ad5cb9c940: command not found
| [INFO] validating against known patches  (standard-yocto-meta)
error: arch/x86/boot/compressed/eboot.c: does not exist in index09 %)
| To force apply this patch, use 'guilt push -f'
| [ERROR] unable to complete push
| pending patches are:
| Patches directory doesn't exist, try guilt-init
| ERROR. could not update git tree
| ERROR: Function 'do_patch' failed (see 
/build/poky/ie/tmp/work/ie_phase1-poky-linux/linux-yocto-ie-3.0.4+git1+d51b0e743599a41a42e119f29f8dfa89854b3b5e_1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r4/temp/log.do_patch.2768
 for further information)

and meta/patches/standard/series contains:

$ cat standard/series
links/scratch/obj/0002-x86-efi-Make-efi_call_phys_prelog-CONFIG_RELOCATABLE.patch
links/scratch/obj/0003-x86-Don-t-use-magic-strings-for-EFI-loader-signature.patch
links/scratch/obj/0004-efi.h-Add-struct-definition-for-boot-time-services.patch
links/scratch/obj/0005-efi.h-Add-efi_image_loaded_t.patch
links/scratch/obj/0011-x86-efi-Break-up-large-initrd-reads.patch

This needs to come after 10.

links/scratch/obj/0007-efi.h-Add-graphics-protocol-guids.patch
links/scratch/obj/0001-x86-Add-missing-bzImage-fields-to-struct-setup_heade.patch
links/scratch/obj/0009-efi-Add-EFI-file-I-O-data-types.patch
links/scratch/obj/0008-efi.h-Add-boottime-locate_handle-search-types.patch
links/scratch/obj/0006-efi.h-Add-allocation-types-for-boottime-allocate_pag.patch
links/scratch/obj/0010-x86-efi-EFI-boot-stub-support.patch

Re: [yocto] linux-yocto: doesn't maintain patch order from SRC_URI?

[Bruce Ashfield]

On 11-11-29 07:41 PM, Darren Hart wrote:



On 11/29/2011 03:14 PM, Bruce Ashfield wrote:

On 11-11-29 04:39 PM, Darren Hart wrote:

I'm experimenting with Matt Fleming's EFI_STUB patches. The first 10 patches 
were working fine, but when I try to add the 11th, the do_patch fails. I found 
that it isn't trying to apply the patches in the order listed in the recipe - 
no in any other recognizable pattern for that matter.



It's shell order. You really should just create a .scc file, put IT
on the SRC_URI and list the patches. You'll have no problems after
that.

I do have a fix for this, but can't send it right now due to travel.

You are using the compatibility mode for more than I originally intended
it for. So just dropping a .scc file into place will fix things
up nicely.


OK, I like that better than the monolith patch I plugged the leak with :-)

I understand I am using the compatibility mode more than the original
intent - and in part I'm doing this on purpose. The "recipe-space"
iterative development model is going to be the most familiar to OE
developers and is the fastest way to prototype changes. We need to
ensure it works well. Once I'm done here, I fully intend to push it into
a proper in-tree scc file - but for now, it makes the most sense in
recipe-space while we tweak it and the patches are under heavy development.


Agreed. There's nothing wrong with this model, and you are just doing
something that I hadn't tried until now. The fixes were simple, so I
definitely wouldn't leave this broken. As I said in my other email, I'm
just now looking at how to integrate this nicely and not duplicate SRC_URI
parsing code.

Cheers,

Bruce



Thanks Bruce!

--
Darren



Bruce


The recipe contains:

# Add the efi-stub
SRC_URI += 
"file://0001-x86-Add-missing-bzImage-fields-to-struct-setup_heade.patch \
  
file://0002-x86-efi-Make-efi_call_phys_prelog-CONFIG_RELOCATABLE.patch \
  
file://0003-x86-Don-t-use-magic-strings-for-EFI-loader-signature.patch \
  
file://0004-efi.h-Add-struct-definition-for-boot-time-services.patch \
  file://0005-efi.h-Add-efi_image_loaded_t.patch \
  
file://0006-efi.h-Add-allocation-types-for-boottime-allocate_pag.patch \
  file://0007-efi.h-Add-graphics-protocol-guids.patch \
  file://0008-efi.h-Add-boottime-locate_handle-search-types.patch \
  file://0009-efi-Add-EFI-file-I-O-data-types.patch \
  file://0010-x86-efi-EFI-boot-stub-support.patch \
file://0011-x86-efi-Break-up-large-initrd-reads.patch \
  "

do_patch fails with:
Log data follows:
| Deleted branch meta-temp (was 620917d).
| warning: could not find (or was already included): ktypes/yocto.scc
| ./0-standard-yocto-61b5e146f9d113375883df8c51449722.sco: line 14: 
yocto_68b329da9893e34099c7d8ad5cb9c940: command not found
| [INFO] validating against known patches  (standard-yocto-meta)
error: arch/x86/boot/compressed/eboot.c: does not exist in index09 %)
| To force apply this patch, use 'guilt push -f'
| [ERROR] unable to complete push
| pending patches are:
| Patches directory doesn't exist, try guilt-init
| ERROR. could not update git tree
| ERROR: Function 'do_patch' failed (see 
/build/poky/ie/tmp/work/ie_phase1-poky-linux/linux-yocto-ie-3.0.4+git1+d51b0e743599a41a42e119f29f8dfa89854b3b5e_1+6b2c7d65b844e686eae7d5cccb9b638887afe28e-r4/temp/log.do_patch.2768
 for further information)

and meta/patches/standard/series contains:

$ cat standard/series
links/scratch/obj/0002-x86-efi-Make-efi_call_phys_prelog-CONFIG_RELOCATABLE.patch
links/scratch/obj/0003-x86-Don-t-use-magic-strings-for-EFI-loader-signature.patch
links/scratch/obj/0004-efi.h-Add-struct-definition-for-boot-time-services.patch
links/scratch/obj/0005-efi.h-Add-efi_image_loaded_t.patch
links/scratch/obj/0011-x86-efi-Break-up-large-initrd-reads.patch

This needs to come after 10.

links/scratch/obj/0007-efi.h-Add-graphics-protocol-guids.patch
links/scratch/obj/0001-x86-Add-missing-bzImage-fields-to-struct-setup_heade.patch
links/scratch/obj/0009-efi-Add-EFI-file-I-O-data-types.patch
links/scratch/obj/0008-efi.h-Add-boottime-locate_handle-search-types.patch
links/scratch/obj/0006-efi.h-Add-allocation-types-for-boottime-allocate_pag.patch
links/scratch/obj/0010-x86-efi-EFI-boot-stub-support.patch









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

Re: [yocto] linux-yocto: doesn't maintain patch order from SRC_URI?

[Bruce Ashfield]

On Tue, Nov 29, 2011 at 8:21 PM, Darren Hart  wrote:
> On 11/29/2011 05:15 PM, Darren Hart wrote:
>> On 11/29/2011 04:41 PM, Darren Hart wrote:
>>>
>>>
>>> On 11/29/2011 03:14 PM, Bruce Ashfield wrote:
>>>> On 11-11-29 04:39 PM, Darren Hart wrote:
>>>>> I'm experimenting with Matt Fleming's EFI_STUB patches. The first 10 
>>>>> patches were working fine, but when I try to add the 11th, the do_patch 
>>>>> fails. I found that it isn't trying to apply the patches in the order 
>>>>> listed in the recipe - no in any other recognizable pattern for that 
>>>>> matter.
>>>>>
>>>>
>>>> It's shell order. You really should just create a .scc file, put IT
>>>> on the SRC_URI and list the patches. You'll have no problems after
>>>> that.
>>>>
>>>> I do have a fix for this, but can't send it right now due to travel.
>>>>
>>>> You are using the compatibility mode for more than I originally intended
>>>> it for. So just dropping a .scc file into place will fix things
>>>> up nicely.
>>>
>>> OK, I like that better than the monolith patch I plugged the leak with :-)
>>
>> So I'm trying this:
>>
>> $ cat linux-yocto-dvhart/efi-stub.scc
>> patch 0001-x86-Add-missing-bzImage-fields-to-struct-setup_heade.patch
>> patch 0002-x86-efi-Make-efi_call_phys_prelog-CONFIG_RELOCATABLE.patch
>> patch 0003-x86-Don-t-use-magic-strings-for-EFI-loader-signature.patch
>> patch 0004-efi.h-Add-struct-definition-for-boot-time-services.patch
>> patch 0005-efi.h-Add-efi_image_loaded_t.patch
>> patch 0006-efi.h-Add-allocation-types-for-boottime-allocate_pag.patch
>> patch 0007-efi.h-Add-graphics-protocol-guids.patch
>> patch 0008-efi.h-Add-boottime-locate_handle-search-types.patch
>> patch 0009-efi-Add-EFI-file-I-O-data-types.patch
>> patch 0010-x86-efi-EFI-boot-stub-support.patch
>> patch 0011-x86-efi-Break-up-large-initrd-reads.patch
>>
>> And in the recipe:
>> SRC_URI += "file://efi-stub.scc"
>>
>> In the meta-series I see:
>>
>> # _mark efi_stub_947530aea4d2a819b340fe2b49d765de start
>> # _mark efi_stub_947530aea4d2a819b340fe2b49d765de end
>>
>> But the patches do not get applied.
>>
>> The Yocto Kernel Architecture and Use Manual does not appear to cover
>> this case. Do I need to do something more?
>
> Ah, I need to include the patches explicitly too. That makes sense from
> a bitbake perspective. OK, I'm rolling again, nice.

Glad to hear you got to this, after I sent that email and headed for some sleep,
I realized that I forgot to point out that detail.

Cheers

Bruce

>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] how to cleanly exit a QEMU session?

[Bruce Ashfield]

On 11-11-30 05:31 PM, Joshua Lock wrote:

On 30/11/11 03:46, Robert P. J. Day wrote:

On Wed, 30 Nov 2011, Paul Eggleton wrote:


On Tuesday 29 November 2011 18:00:31 Robert P. J. Day wrote:

   i'm sure it's in one of the docs i missed, but how does one cleanly
shut down a QEMU session and get back to the original terminal
session?  i've tried shutdown and poweroff but neither of those gives
me my shell prompt back.


Which machine are you running within the emulator? I know some emulated
machines don't seem to support actually powering off - does reboot work?


   qemuppc, core-image-minimal.  interestingly, "poweroff" doesn't
completely close the QEMU session, but "reboot" does.  it might be
worth adding that to the quick start guide.


The same is also true for qemuarm, we work around it in sato by munging
the shutdown.desktop file to all restart and having the qemu scripts
start qemu with -norestart.

Clearly we should also do the shutdown.desktop munging for qemuppc

What do people think to the idea of putting something into the image for
those two specific machines which aliases poweroff to reboot?


I'd be fine with such a change, I pushed for the ARM mapping to
reboot originally, so doing the same here and an alias would make
the command line consistent with the GUI.

Bruce



Joshua


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

Re: [yocto] how to cleanly exit a QEMU session?

[Bruce Ashfield]

On 11-11-30 05:47 PM, Wolfgang Denk wrote:

Dear Joshua Lock,

In message<4ed6aed5.8070...@linux.intel.com>  you wrote:


What do people think to the idea of putting something into the image for
those two specific machines which aliases poweroff to reboot?


I consider it a really bad idea, as "poweroff" is actually a very
different action than "reboot" - the former should shut down and halt
the system, while the latter should actually restart it.

It appears both operations are not properly working and need to be


The hardware that qemu 'models' in both cases doesn't perform
this function either, so the behaviour is consistent. We looked
into fix it, and quite frankly, there was very little value in
fixing it, so simply using reboot was good enough given the scope
of the problem.

Cheers,

Bruce


fixed.

Best regards,

Wolfgang Denk



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

Re: [yocto] [PATCH 0/3][linux-yocto-3.0] EFI support backports

[Bruce Ashfield]

On 11-12-07 02:19 PM, Darren Hart wrote:

From: Darren Hart

The following patches have been merged back from upstream to address various
issues with the EFI boot process. These are intended to be merged with
yocto/standard/base.

Please watch for a subsequent patch adding a series of efi config fragments.


Merged to base and all the BSP branches. I've put it in with my
pending 3.0.12 pull request, which should be out ASAP.

Bruce



The following changes since commit ab1de8c21d2b1d084b8488496d75cc54fcd94f02:

   Merge commit 'v3.0.10' into yocto/standard/base (2011-11-23 00:31:29 -0500)

are available in the git repository at:

   git://git.infradead.org/users/dvhart/linux-yocto-3.0.git dvhart/standard/efi
   
http://git.infradead.org/users/dvhart/linux-yocto-3.0.git/shortlog/refs/heads/dvhart/standard/efi

Matt Fleming (2):
   x86/rtc: Don't recursively acquire rtc_lock
   x86, efi: Make efi_call_phys_prelog() CONFIG_RELOCATABLE-aware

Maurice Ma (1):
   x86, efi: Convert efi_phys_get_time() args to physical addresses

  arch/x86/kernel/rtc.c  |   23 ---
  arch/x86/platform/efi/efi.c|3 ++-
  arch/x86/platform/efi/efi_32.c |   22 +-
  arch/x86/platform/mrst/vrtc.c  |9 +
  4 files changed, 36 insertions(+), 21 deletions(-)



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

Re: [yocto] [PATCH 0/1][linux-yocto-3.0] EFI config fragments

[Bruce Ashfield]

On 11-12-07 5:50 PM, Darren Hart wrote:

The following changes since commit 67ce7623909cef63927fd145026aaf371cf4abf1:

   meta: bumping kver to v3.0.10 (2011-11-23 00:33:19 -0500)


Merged. Will push it out in the morning.

Bruce



are available in the git repository at:
   git://git.infradead.org/users/dvhart/linux-yocto-3.0.git dvhart/meta/efi
   
http://git.infradead.org/users/dvhart/linux-yocto-3.0.git/shortlog/refs/heads/dvhart/meta/efi

Darren Hart (1):
   Add EFI scc and cfg files

  meta/cfg/kernel-cache/cfg/efi-ext.cfg |   14 ++
  meta/cfg/kernel-cache/cfg/efi-ext.scc |2 ++
  meta/cfg/kernel-cache/cfg/efi.cfg |8 
  meta/cfg/kernel-cache/cfg/efi.scc |1 +
  4 files changed, 25 insertions(+), 0 deletions(-)
  create mode 100644 meta/cfg/kernel-cache/cfg/efi-ext.cfg
  create mode 100644 meta/cfg/kernel-cache/cfg/efi-ext.scc
  create mode 100644 meta/cfg/kernel-cache/cfg/efi.cfg
  create mode 100644 meta/cfg/kernel-cache/cfg/efi.scc



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

Re: [yocto] Variable locality too restricted.

[Bruce Ashfield]

On Thu, Dec 8, 2011 at 2:24 AM, David Nyström  wrote:
>
> 
> From: Koen Kooi [k...@dominion.thruhere.net]
> Sent: Wednesday, December 07, 2011 15:07
> To: Paul Eggleton
> Cc: Chris Larson; David Nyström; yocto@yoctoproject.org
> Subject: Re: [yocto] Variable locality too restricted.
>
> Op 7 dec. 2011, om 15:05 heeft Paul Eggleton het volgende geschreven:
>
>> On Wednesday 07 December 2011 06:52:25 Chris Larson wrote:
>>> On Wed, Dec 7, 2011 at 6:44 AM, David Nyström 
>> wrote:
 I'm trying to create a setup for qemuppc.

 Goals:
 core-image-minimal + virtual/kernel.
 core-image-minimal + virtual/kernel with modified .config for debug
 flavoured kernel.

 Problems:
 PREFERRED_PROVIDER seems to be restricted to local.conf, distro and
 machine.
>>> This is incorrect. It can be anywhere in the configuration metadata.
>>> bitbake.conf includes a variety of config files, not just
>>> distro/machine. Read that to see other existing files which get
>>> included. Further, you could create a .conf/.inc which you include
>>> from your machine .conf, if your goal is just to avoid duplication.
>>
>> Changing MACHINE has other implications though; do we not have any other way
>> to switch out the kernel on a per-image basis?
>
> And how would that work from a packaging perspective? AIUI changing 
> DISTRO/MACHINE flags in an image is a recipe for failure.
>
> regards,
>
> Koen
> Op 7 dec. 2011, om 15:10 heeft Paul Eggleton het volgende geschreven:
>
> --
>> On Wednesday 07 December 2011 15:07:54 Koen Kooi wrote:
 Changing MACHINE has other implications though; do we not have any other
 way to switch out the kernel on a per-image basis?
>>>
>>> And how would that work from a packaging perspective? AIUI changing
>>> DISTRO/MACHINE flags in an image is a recipe for failure.
>>
>> I'm not suggesting changing the kernel configuration for the existing kernel;
>> naturally you would need a different kernel recipe. Surely you should just be
>> able to have a different kernel that is built and installed for a different
>> image file? No invalidated packages necessary.
>
> A kernel buld will generate packages and thanks to kernel.bbclass they will 
> have similar names. So what will happen when I do:
>
> bitbake foo-image bar-image
>
> ? Will it build 2 kernels? Which kernel will end up being packaged or will 
> there be a mix of both in deploy?
>
> regards,
>
> Koen
>
> --
>
> Different virtual/kernel recipies depending on kernel configuration might not 
> be the best resolution path for this issue.
>
> How would it be problematic to have multiple binary flavour packages(Still a 
> single source package)
> of the same kernel with the same linux-headers in the distro packages ?
> In deploy/images a similiar notation as for rootfs could be used.
> Perhaps there are no mechanisms today to do this, but perhaps there 
> could/should be ?
> What about a pkgconfig style approach ?
>
> poky configuration contains a logical separation of IMAGE, MACHINE and 
> DISTRO. (Probably more, but this is unrelated to my point below).
> What is the roadmap and future of this separation ?
>
> image:
> The IMAGE may contain user applications that will not function without the 
> proper kernel modules.(Or possibly non-module available .config items).
> i.e. RDEPENDS = kernel-module- will is impossible to automate since it 
> only scans kernel build for its existence.(if it was configured by kernel 
> .config monolith selected by MACHINE)
> This is solved in most recipies as RRECOMMENDS = kernel-module-xxx to avoid 
> build breakage.
>
> So you need to configure your kernel to support all your IMAGEs, from 
> core-image-smaller-than-minimal to core-image-huge-system(or in my case 
> debug, profiling)
> This is especially problematic for small embedded systems when it comes to 
> debug and profiling, where included kernel configuration(depending on exactly 
> what)
> will have varying degrees of performance impact.(some huge, others we can 
> probably live with).
>
> machine:
> In my head, this would contain machine specific configuration and not deal 
> with other kernel configuration.
> In edison, the kernel configuration is treated as a monolith, perhaps we can 
> improve this by allowing for a more dynamic configuration model of the 
> kernel, where the
> machine logical layer would depend on _only_ the machine specific parts of 
> the kernel configuration. In the current(edison) case, it usually uses a 
> defconfig.
> Great, but let the build modify it.
>
> pipedream:
> 1. MACHINE selects a defconfig.
> 2. IMAGE selects packets on rootfs, some depend on kernel-module-xx, or 
> kernel-config-xx.
> 3. When building image, fist stage scans included recipes for kernel-module-* 
> and kernel-config-* and adds this to the MACHINE selected defconfig before 
> building kernel.

Hi David,

For what it's worth, if you use the linux-yocto tooling/base kernel,
there are

Re: [yocto] linux-yocto: ktypes/tiny and some questions along the way

[Bruce Ashfield]

On 11-12-09 5:52 PM, Darren Hart wrote:

Bruce,

I'm looking at introducing a new kernel type, ktypes/tiny.

Tiny will define a core set of kernel policy options, such as proc, sys,
devtmpfs, futex, epoll, elf bin format, etc. It will not enable any
drivers, filesystems, debug options, or networking options by default.
This would be the responsibility of the BSP to add a named feature
implementing this.

Taking a look at the ktypes we have now resulted in some questions:

dvhart@envy:~/source/linux/linux-yocto-3.0/meta/cfg/kernel-cache/ktypes
$ tree
.
├── base
│   ├── base.cfg
│   ├── base.scc
│   ├── hardware.cfg
│   ├── hardware.kcf
│   ├── non-hardware.cfg
│   └── non-hardware.kcf
├── preempt-rt
│   ├── preempt-rt.cfg
│   └── preempt-rt.scc
├── standard
│   ├── perf-force-include-of-stdbool.h.patch
│   ├── perf-hard-code-NO_LIBPERL-NO_LIBPYTHON.patch
│   ├── standard-patches.scc
│   ├── standard.cfg
│   ├── standard.scc
│   └── x86-add-TIF_32BIT-compatibility-define.patch

These form a hiearchy, each inheriting from the layer beneath like so:

base/standard/preempt-rt

As I dig into this I see that some policy is infact laid down by base,
including things like:

CONFIG_MODULES=y
CONFIG_INET=y
CONFIG_PREEMPT=y
CONFIG_NFS_FS=y
CONFIG_MSDOS_PARTITION=y

These pull in the IP stack, the block layer, etc. Because of this, I
can't really inherit from base for ktypes/tiny. I would like to inherit
the hardware and non-hardware kcf files though, as well as any patches
that might make their way into base. Which leads me to standard. I would
like to see a much smaller set of config policy options set in base.
Most likely these should be exactly what we agree on for tiny, and tiny
wouldn't add any additional policy as it implements only what is
required for a Yocto Project built kernel.

NOTE: kernel version is 3.0+
$ cat base/base.scc | head -n 1
set_kernel_version 2.6.37

There are three patches in standard, only two of which (the perf ones)
are listed in the standard.scc. As I believe any kernel we build should
have these, I would like to see any global patches applied to base,
leaving standard to define policy, and include named features.

With these changes, I could add ktypes/tiny as follows:
$ cat tiny/tiny.scc
include ktypes/base
branch tiny
include features/xyz/xyz.scc
include cfg/abc.scc

Another point of interest is preempt-rt, as I can see people wanting to
build tiny preempt-rt. I think the best approach here is to create
ktypes/tiny/preempt-rt-tiny/preempt-rt-tiny.scc.

Note: I believe this fails with .patch.patch
$ cat features/rt/rt.scc | grep patch
patch rt-apply-patch-3.0.10-rt27.patch.patch

I'm working on a patch series that implements the suggestions I've made
above. Bruce, do you have any issues with this approach?


FYI: I have a response to this .. but it's just not reading very well here.
And it's late, so I'm going to respond over the weekend when I get a
chance to revise what I've written into something legible. :)

Cheers,

Bruce





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

Re: [yocto] linux-yocto: ktypes/tiny and some questions along the way

[Bruce Ashfield]

On 11-12-09 5:52 PM, Darren Hart wrote:

Bruce,

I'm looking at introducing a new kernel type, ktypes/tiny.

Tiny will define a core set of kernel policy options, such as proc, sys,
devtmpfs, futex, epoll, elf bin format, etc. It will not enable any
drivers, filesystems, debug options, or networking options by default.
This would be the responsibility of the BSP to add a named feature
implementing this.

Taking a look at the ktypes we have now resulted in some questions:

dvhart@envy:~/source/linux/linux-yocto-3.0/meta/cfg/kernel-cache/ktypes
$ tree
.
├── base
│   ├── base.cfg
│   ├── base.scc
│   ├── hardware.cfg
│   ├── hardware.kcf
│   ├── non-hardware.cfg
│   └── non-hardware.kcf
├── preempt-rt
│   ├── preempt-rt.cfg
│   └── preempt-rt.scc
├── standard
│   ├── perf-force-include-of-stdbool.h.patch
│   ├── perf-hard-code-NO_LIBPERL-NO_LIBPYTHON.patch
│   ├── standard-patches.scc
│   ├── standard.cfg
│   ├── standard.scc
│   └── x86-add-TIF_32BIT-compatibility-define.patch

These form a hiearchy, each inheriting from the layer beneath like so:

base/standard/preempt-rt

As I dig into this I see that some policy is infact laid down by base,
including things like:

CONFIG_MODULES=y
CONFIG_INET=y
CONFIG_PREEMPT=y
CONFIG_NFS_FS=y
CONFIG_MSDOS_PARTITION=y

These pull in the IP stack, the block layer, etc. Because of this, I
can't really inherit from base for ktypes/tiny. I would like to inherit
the hardware and non-hardware kcf files though, as well as any patches
that might make their way into base. Which leads me to standard. I would
like to see a much smaller set of config policy options set in base.
Most likely these should be exactly what we agree on for tiny, and tiny
wouldn't add any additional policy as it implements only what is
required for a Yocto Project built kernel.

NOTE: kernel version is 3.0+
$ cat base/base.scc | head -n 1
set_kernel_version 2.6.37


FYI: nothing uses this at the moment. But I fixed that here.



There are three patches in standard, only two of which (the perf ones)
are listed in the standard.scc. As I believe any kernel we build should
have these, I would like to see any global patches applied to base,
leaving standard to define policy, and include named features.


standard only includes 3 patches because they were a bit hard to
classify elsewhere. In a more fully populated kernel, it does include
quite a bit more directly.



With these changes, I could add ktypes/tiny as follows:
$ cat tiny/tiny.scc
include ktypes/base
branch tiny
include features/xyz/xyz.scc
include cfg/abc.scc

Another point of interest is preempt-rt, as I can see people wanting to
build tiny preempt-rt. I think the best approach here is to create
ktypes/tiny/preempt-rt-tiny/preempt-rt-tiny.scc.

Note: I believe this fails with .patch.patch
$ cat features/rt/rt.scc | grep patch
patch rt-apply-patch-3.0.10-rt27.patch.patch


Love my "patch.patch". Script went wild on that one, luckily the content
in the branch is king :) I fixed that here when I was auditing 3.0.12+rt
so that looks more sane now.



I'm working on a patch series that implements the suggestions I've made
above. Bruce, do you have any issues with this approach?


Allow me to ramble a bit below ...

No big issues. At some level(s) it is just a shell game. We can move
configs and patches around to the appropriate level to get the building
blocks that we need and get common functionality into a common location.

base was (is) intended to document the branch point from the mainline
kernel, and contain largely configuration and very few patches. Any
important or larger size functional additions go into the standard
kernel.

So branching from base for a new kernel type is something we can do, but
it will risk missing additions (say for example tracing fixes, or the
next super-duper debug via kprobes patch series), since they'll go into
the standard kernel. If I just slide all the patches down into base,
why not just call 'base' 'standard' or just make standard have the
configuration you are working on for tiny.

The point I'm attempting to make, is that the base/common point can be
whatever we decide it needs to be, "standard" can be renamed, content
moved up and down, etc. i.e. standard could have it's config changed,
a new branch created off standard ( and options moved there), or
standard  could be streamlined and the boards include more common
config options manually vs inheriting them, etc.

I need a bit more time to think about that myself.

Another option is to let tiny inherit from standard, but force a
new baseline for configuration options. i.e. your allnoconfig
technique buried in the middle of inheritance tree. With the
optional/required designations I'm finishing up for 1.2 you won't get
hit with reams of redefined configuration warnings. With that set, you
can then go about adding kernel type specific options/features/patches
as we see fit .. and you'll pickup those features that I was talking
about above. If you bear with me by 

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bruce Ashfield]

On 11-12-13 5:50 PM, Bodke, Kishore K wrote:

Hi,

I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.

Darren told that it was fixed and merged to master.


This shouldn't be happening on edison at all. The changes to the
kernel recipes/tools to use the merge_config.sh should never have
showed up in edison. That's yocto 1.2 development work.

So the fix for this is to find out what leaked into edison and
revert it. I'll have a look at that later tonight.

Bruce



I wanted to bring to the list about this error message.

ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

ERROR: Logfile of failure stored in:
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502

Log data follows:

| [INFO] doing kernel configme

| [INFO] Branch yocto/standard/preempt-rt/base used by
common-pc-preempt-rt.scc

| [INFO] collecting configs in ./meta/meta-series

| mv: cannot stat
`/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
No such file or directory

| creation of pre-processed config data failed

| config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed

| ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

NOTE: package
linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
task do_kernel_configme: Failed

ERROR: Task 716
(/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
do_kernel_configme) failed with exit code '1'

Waiting for 7 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)

4: bison-native-2.5-r1 do_configure (pid 20206)

5: dbus-native-1.4.12-r0 do_configure (pid 20209)

6: opensp-native-1.5-r2 do_configure (pid 20213)

Waiting for 6 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)

4: bison-native-2.5-r1 do_configure (pid 20206)

5: dbus-native-1.4.12-r0 do_configure (pid 20209)

NOTE: package opensp-native-1.5-r2: task do_configure: Succeeded

Waiting for 5 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: bison-native-2.5-r1 do_configure (pid 20206)

4: dbus-native-1.4.12-r0 do_configure (pid 20209)

NOTE: package font-util-native-1.2.0-r2.1: task do_configure: Succeeded

Waiting for 4 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: bison-native-2.5-r1 do_configure (pid 20206)

NOTE: package dbus-native-1.4.12-r0: task do_configure: Succeeded

Waiting for 3 active tasks to finish:

0: elfutils-native-0.148-r3 do_install (pid 19851)

1: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

2: bison-native-2.5-r1 do_configure (pid 20206)

NOTE: package acl-native-2.2.51-r2: task do_configure: Succeeded

Waiting for 2 active tasks to finish:

0: elfutils-native-0.148-r3 do_install (pid 19851)

1: bison-native-2.5-r1 do_configure (pid 20206)

NOTE: package kbproto-native-1_1.0.5-r0: task do_configure: Succeeded

Waiting for 1 active tasks to finish:

0: bison-native-2.5-r1 do_configure (pid 20206)

NOTE: package elfutils-native-0.148-r3: task do_install: Succeeded

NOTE: package bison-native-2.5-r1: task do_configure: Succeeded

ERROR:
'/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb'
failed

Thanks

Kishore.



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

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bruce Ashfield]

On 11-12-13 6:17 PM, Bodke, Kishore K wrote:

Yeah.  I am using local bare clone for the linux-yocto-3.0 and using 
poky-extras/meta-kernel-dev in my bblayers.conf for my build.
Sorry for not mentioning this before.


Aha. This is completely different then. As Darren mentioned, the bbappend
should be getting the latest tools, I can look into that.

But to be clear, is this an edison branch + meta-kernel-dev ? That
will cause problems at some point (and I'm not sure if that is what
is happening here yet), since recipe updates to use the new tools
wouldn't be reflected in that branch while you are fed the new tools.

Cheers,

Bruce



Thanks
Kishore.

-Original Message-
From: Hart, Darren
Sent: Tuesday, December 13, 2011 3:15 PM
To: Bruce Ashfield
Cc: Bodke, Kishore K; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 12/13/2011 03:05 PM, Bruce Ashfield wrote:

On 11-12-13 5:50 PM, Bodke, Kishore K wrote:

Hi,

I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.

Darren told that it was fixed and merged to master.


This shouldn't be happening on edison at all. The changes to the
kernel recipes/tools to use the merge_config.sh should never have
showed up in edison. That's yocto 1.2 development work.

So the fix for this is to find out what leaked into edison and
revert it. I'll have a look at that later tonight.


No no. Kishore is using meta-kernel-dev. As such he is getting the
latest linux-yocto repository and SRC_REVs. The question, I think, is
really why isn't the kern-tools-native bbappend from meta-kernel-dev
doing this for him.

--
Darren



Bruce



I wanted to bring to the list about this error message.

ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

ERROR: Logfile of failure stored in:
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502

Log data follows:

| [INFO] doing kernel configme

| [INFO] Branch yocto/standard/preempt-rt/base used by
common-pc-preempt-rt.scc

| [INFO] collecting configs in ./meta/meta-series

| mv: cannot stat
`/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
No such file or directory

| creation of pre-processed config data failed

| config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed

| ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

NOTE: package
linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
task do_kernel_configme: Failed

ERROR: Task 716
(/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
do_kernel_configme) failed with exit code '1'

Waiting for 7 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)

4: bison-native-2.5-r1 do_configure (pid 20206)

5: dbus-native-1.4.12-r0 do_configure (pid 20209)

6: opensp-native-1.5-r2 do_configure (pid 20213)

Waiting for 6 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)

4: bison-native-2.5-r1 do_configure (pid 20206)

5: dbus-native-1.4.12-r0 do_configure (pid 20209)

NOTE: package opensp-native-1.5-r2: task do_configure: Succeeded

Waiting for 5 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: bison-native-2.5-r1 do_configure (pid 20206)

4: dbus-native-1.4.12-r0 do_configure (pid 20209)

NOTE: package font-util-native-1.2.0-r2.1: task do_configure: Succeeded

Waiting for 4 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: bison-native-2.5-r1 do

Re: [yocto] Error in routerstation pro machine.conf?

[Bruce Ashfield]

On 11-12-13 6:05 PM, David Smoot wrote:

I'm still very new and very clueless but I humbly submit what looks like
a bug to me..

"routerstationpro.conf" in meta-yocto/conf/machine/ lists machine
features the hardware does not have.

http://www.ubnt.com/wiki/RouterStation_Pro lists the hardware specs and
it lacks a display adapter (hence no screen nor keyboard) and it also
lacks USB slave hardware (hence no point in usbgadget).

File a bugzilla report or is there a reason for that configuration?


It's based off a generic MIPS configuration, the extra configs are there
from that effort and do no harm at the moment, so I'm inclined to leave
them as is. i.e. screen doesn't really trigger anything to be added
to the image (last I checked anyway), and keyboard gets us the keymaps
(which IIRC is used on the console). So neither does any harm.

gadget on the other hand, doesn't do us any good.

The boards features are planned to be documented in a README file,
rather than the conf file.

We have an update for this to the 3.0 kernel shortly which will include
the mentioned README file.

But a low level bugzilla can't hurt for the gadget issue. We can fix
it while updating the board.

Cheers,

Bruce




David

David Smoot
davidsm...@gmail.com 





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


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

Re: [yocto] linux-libc-headers 2.6.37

[Bruce Ashfield]

On 11-12-13 6:33 PM, Darren Hart wrote:

We currently build at least some MACHINES with 2.6.37 of
linux-libc-headers. This can cause problems for newer packages (such as
connman) that expect more recent headers (if_alg.h is missing prior to
2.6.39). While the proper fix is to ensure these packages can cope with
older headers, for MACHINES shipping 3.0+ kernels, seems to me we should
be using the linux-libc-headers matching the kernels. I know this has
come up in the past, but I don't recall if we have clearly stated and
justified what our policy is here.


They should match were possible. I updated master to have 3.0 and 3.1
headers and no longer have .37 as the default.

Where is the 2.6.37 trickling in ? i.e. which boards/branch ?

Bruce



Any thoughts on this?



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

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bruce Ashfield]

On 11-12-13 6:26 PM, Bodke, Kishore K wrote:

Yes.
Its with poky Edison with poky-extras/meta-kernel-dev master branch I am using 
for my build.


This is likely the problem. I use and test meta-kernel-dev everyday,
but that's always against master. I keep them in lockstep, since
meta-kernel-dev never really 'releases'.

That being said, we can figure out a combination that works. The
best thing to do, would be to remove the kern-tools-native bbappend
from your meta-kernel-dev layer (for now). You don't want the new
tools.

If that doesn't fix the problem, look for merge_log.txt in your
linux/meta/cfg/ directory structure and that will tell us exactly
what is going wrong.

Bruce



Thanks
Kishore.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, December 13, 2011 3:25 PM
To: Bodke, Kishore K
Cc: Hart, Darren; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 11-12-13 6:17 PM, Bodke, Kishore K wrote:

Yeah.  I am using local bare clone for the linux-yocto-3.0 and using 
poky-extras/meta-kernel-dev in my bblayers.conf for my build.
Sorry for not mentioning this before.


Aha. This is completely different then. As Darren mentioned, the bbappend
should be getting the latest tools, I can look into that.

But to be clear, is this an edison branch + meta-kernel-dev ? That
will cause problems at some point (and I'm not sure if that is what
is happening here yet), since recipe updates to use the new tools
wouldn't be reflected in that branch while you are fed the new tools.

Cheers,

Bruce



Thanks
Kishore.

-Original Message-
From: Hart, Darren
Sent: Tuesday, December 13, 2011 3:15 PM
To: Bruce Ashfield
Cc: Bodke, Kishore K; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 12/13/2011 03:05 PM, Bruce Ashfield wrote:

On 11-12-13 5:50 PM, Bodke, Kishore K wrote:

Hi,

I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.

Darren told that it was fixed and merged to master.


This shouldn't be happening on edison at all. The changes to the
kernel recipes/tools to use the merge_config.sh should never have
showed up in edison. That's yocto 1.2 development work.

So the fix for this is to find out what leaked into edison and
revert it. I'll have a look at that later tonight.


No no. Kishore is using meta-kernel-dev. As such he is getting the
latest linux-yocto repository and SRC_REVs. The question, I think, is
really why isn't the kern-tools-native bbappend from meta-kernel-dev
doing this for him.

--
Darren



Bruce



I wanted to bring to the list about this error message.

ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

ERROR: Logfile of failure stored in:
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502

Log data follows:

| [INFO] doing kernel configme

| [INFO] Branch yocto/standard/preempt-rt/base used by
common-pc-preempt-rt.scc

| [INFO] collecting configs in ./meta/meta-series

| mv: cannot stat
`/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
No such file or directory

| creation of pre-processed config data failed

| config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed

| ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.18502
for further information)

NOTE: package
linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
task do_kernel_configme: Failed

ERROR: Task 716
(/usr/local/src/yocto_1_1_release/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
do_kernel_configme) failed with exit code '1'

Waiting for 7 active tasks to finish:

0: acl-native-2.2.51-r2 do_configure (pid 12164)

1: elfutils-native-0.148-r3 do_install (pid 19851)

2: kbproto-native-1_1.0.5-r0 do_configure (pid 20113)

3: font-util-native-1.2.0-r2.1 do_configure (pid 14632)

4: bison-native-2.5-r1 do_configure (pid 20206)

5: dbus-native-1.4.12-r0 do_configure (pid 20209)

6: opensp-native-1.5-r2 do_configure (pid 20213)

Waiting fo

Re: [yocto] linux-libc-headers 2.6.37

[Bruce Ashfield]

On 11-12-13 6:43 PM, Darren Hart wrote:



On 12/13/2011 03:41 PM, Bruce Ashfield wrote:

On 11-12-13 6:33 PM, Darren Hart wrote:

We currently build at least some MACHINES with 2.6.37 of
linux-libc-headers. This can cause problems for newer packages (such as
connman) that expect more recent headers (if_alg.h is missing prior to
2.6.39). While the proper fix is to ensure these packages can cope with
older headers, for MACHINES shipping 3.0+ kernels, seems to me we should
be using the linux-libc-headers matching the kernels. I know this has
come up in the past, but I don't recall if we have clearly stated and
justified what our policy is here.


They should match were possible. I updated master to have 3.0 and 3.1
headers and no longer have .37 as the default.

Where is the 2.6.37 trickling in ? i.e. which boards/branch ?


This was on fri2 yocto/standard/fri2.


What does your: meta/conf/distro/include/tcmode-default.inc have
as the default ? It should be LINUXLIBCVERSION ?= "3.1".

I'm talking about master for that default. In the release branches
it was still back on 2.6.37.

Is that being overridden somewhere in meta-intel that would trigger
the 2.6.37 (the old default) ? I didn't find anything, but that doesn't
mean I didn't miss it.

Bruce





Bruce



Any thoughts on this?







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

Re: [yocto] Using yocto/standard by default

[Bruce Ashfield]

On 11-12-13 6:46 PM, Darren Hart wrote:

We hit another lock-step SRCREV bug earlier on the FRI2 BSP. This was
due mostly to my pushing the efi changes to meta-intel too early - but,
it highlights a maintenance step that I believe could be eliminated for
most boards.

We have a yocto/standard/fri2 branch, but it doesn't contain any
additional changes over yocto/standard/base. If we were to make
yocto/standard/base the default for KBRANCH, shouldn't we be able to
eliminate all the BSP branches that are identical to
yocto/standard/base? This would significantly reduce the number of
SRCREV updates that are required and likely reduce the number of
Autobuilder failures we experience as a result. Seems like it would also
help make the git tree easier to deal with.

Any opinions here?


It's a valid config, and something that works now. So there's no
reason to not use it. New branches can be created IF a board really
does need to merge conflicting patches. The emgd stuff was a problem
and required branches, but if we have nothing like that, squashing the
branches is a nice simplification.

Cheers,

Bruce





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

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bruce Ashfield]

On 11-12-14 12:47 AM, Darren Hart wrote:

On 12/13/2011 09:13 PM, Bruce Ashfield wrote:

On 11-12-13 6:26 PM, Bodke, Kishore K wrote:

Yes.
Its with poky Edison with poky-extras/meta-kernel-dev master branch I am using 
for my build.


This is likely the problem. I use and test meta-kernel-dev everyday,
but that's always against master. I keep them in lockstep, since
meta-kernel-dev never really 'releases'.

That being said, we can figure out a combination that works. The
best thing to do, would be to remove the kern-tools-native bbappend
from your meta-kernel-dev layer (for now). You don't want the new
tools.


That won't work.  He is using the latest kernel which has needs
merge_config.sh - as I ran into myself last week. I had Kishore


There's still a way it will work, merge_config.sh is only ever
called from the kern-tools. There shouldn't be any non kern-tools
calls to merge_config.sh, the error:

 mv: cannot stat
 `/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest- 
poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':

 No such file or directory

Could only come from using the latest configme script from the
kern-tools. So *something* newer than any SRCREV found on the
edison branch is being used there.


cherry-pick the last two patches to kern-tools-native from master and
that got things going for him. So again, the question is: Why didn't the
kern-tools-native bbappend do that for him?


Aha. I may know the answer to that. The meta variant of the recipe looks
to assign the SRCREV in a way that the bbappend can't change. I did
this change during the day, but completely forgot when sending the
email. Can someone try this to see if it's the fix ?

index fb66211..bc9a6b9 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,8 +4,8 @@ LIC_FILES_CHKSUM = 
"file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8


 DEPENDS = "git-native guilt-native"

-SRCREV = "eb3ed64cea80d23ffb28dfeaeb02cdfe3fb29340"
-PR = r12
+SRCREV ?= "eb3ed64cea80d23ffb28dfeaeb02cdfe3fb29340"
+PR = r13
 PV = "0.1+git${SRCPV}"

.. and Then I'll do a pull request.

But as to why it's happening, I have no idea, autorev should pick it
up. That's down in the guts of bitbake, and for some reason the old
downloaded variant doesn't seem to be updating.

Bruce



--
Darren



If that doesn't fix the problem, look for merge_log.txt in your
linux/meta/cfg/ directory structure and that will tell us exactly
what is going wrong.

Bruce



Thanks
Kishore.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, December 13, 2011 3:25 PM
To: Bodke, Kishore K
Cc: Hart, Darren; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 11-12-13 6:17 PM, Bodke, Kishore K wrote:

Yeah.  I am using local bare clone for the linux-yocto-3.0 and using 
poky-extras/meta-kernel-dev in my bblayers.conf for my build.
Sorry for not mentioning this before.


Aha. This is completely different then. As Darren mentioned, the bbappend
should be getting the latest tools, I can look into that.

But to be clear, is this an edison branch + meta-kernel-dev ? That
will cause problems at some point (and I'm not sure if that is what
is happening here yet), since recipe updates to use the new tools
wouldn't be reflected in that branch while you are fed the new tools.

Cheers,

Bruce



Thanks
Kishore.

-Original Message-
From: Hart, Darren
Sent: Tuesday, December 13, 2011 3:15 PM
To: Bruce Ashfield
Cc: Bodke, Kishore K; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 12/13/2011 03:05 PM, Bruce Ashfield wrote:

On 11-12-13 5:50 PM, Bodke, Kishore K wrote:

Hi,

I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.

Darren told that it was fixed and merged to master.


This shouldn't be happening on edison at all. The changes to the
kernel recipes/tools to use the merge_config.sh should never have
showed up in edison. That's yocto 1.2 development work.

So the fix for this is to find out what leaked into edison and
revert it. I'll have a look at that later tonight.


No no. Kishore is using meta-kernel-dev. As such he is getting the
latest linux-yocto repository and SRC_REVs. The question, I think, is
really why isn't the kern-tools-native bbappend from meta-kernel-dev
doing this for him.

--
Darren



Bruce



I wanted to bring to the list about this error message.

ERROR: Function 'do_kernel_configme' failed (see
/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-poky-linux/linux

Re: [yocto] [PATCH 1/1] remove usbgadget from routerstationpro

[Bruce Ashfield]

On 11-12-14 04:31 AM, Zumeng Chen wrote:

   1. No mass storage needed to be accessed by usbgadget.
   2. This is a router station&  switch, so it should not
  be taken as a USB_NET device too.


Zumeng,

The comment from the bug reporter was also that the target
doesn't have USB slave hardware to support usbgadget. So mentioning
that in the header is probably a good idea as well.

And small comment indicating that as a result of these conditions,
we remove usbgadget from MACHINE_FEATURES, since it can't be used.
Would complete the header.

Cheers,

Bruce



Signed-off-by: zumeng.c...@windriver.com>
---
  meta-yocto/conf/machine/routerstationpro.conf |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta-yocto/conf/machine/routerstationpro.conf 
b/meta-yocto/conf/machine/routerstationpro.conf
index 9338ca1..52124d9 100644
--- a/meta-yocto/conf/machine/routerstationpro.conf
+++ b/meta-yocto/conf/machine/routerstationpro.conf
@@ -5,7 +5,7 @@
  require conf/machine/include/tune-mips32.inc

  MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 \
-serial usbgadget"
+serial"

  KERNEL_IMAGETYPE = "vmlinux"
  KERNEL_ALT_IMAGETYPE = "vmlinux.bin"


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

Re: [yocto] linux-yocto: ktypes/tiny and some questions along the way

[Bruce Ashfield]

On 11-12-12 06:17 PM, Darren Hart wrote:

On 12/11/2011 09:14 PM, Bruce Ashfield wrote:

On 11-12-09 5:52 PM, Darren Hart wrote:

Bruce,

I'm looking at introducing a new kernel type, ktypes/tiny.

Tiny will define a core set of kernel policy options, such as proc, sys,
devtmpfs, futex, epoll, elf bin format, etc. It will not enable any
drivers, filesystems, debug options, or networking options by default.
This would be the responsibility of the BSP to add a named feature
implementing this.

Taking a look at the ktypes we have now resulted in some questions:

dvhart@envy:~/source/linux/linux-yocto-3.0/meta/cfg/kernel-cache/ktypes
$ tree
.
├── base
│   ├── base.cfg
│   ├── base.scc
│   ├── hardware.cfg
│   ├── hardware.kcf
│   ├── non-hardware.cfg
│   └── non-hardware.kcf
├── preempt-rt
│   ├── preempt-rt.cfg
│   └── preempt-rt.scc
├── standard
│   ├── perf-force-include-of-stdbool.h.patch
│   ├── perf-hard-code-NO_LIBPERL-NO_LIBPYTHON.patch
│   ├── standard-patches.scc
│   ├── standard.cfg
│   ├── standard.scc
│   └── x86-add-TIF_32BIT-compatibility-define.patch

These form a hiearchy, each inheriting from the layer beneath like so:

base/standard/preempt-rt

As I dig into this I see that some policy is infact laid down by base,
including things like:

CONFIG_MODULES=y
CONFIG_INET=y
CONFIG_PREEMPT=y
CONFIG_NFS_FS=y
CONFIG_MSDOS_PARTITION=y

These pull in the IP stack, the block layer, etc. Because of this, I
can't really inherit from base for ktypes/tiny. I would like to inherit
the hardware and non-hardware kcf files though, as well as any patches
that might make their way into base. Which leads me to standard. I would
like to see a much smaller set of config policy options set in base.
Most likely these should be exactly what we agree on for tiny, and tiny
wouldn't add any additional policy as it implements only what is
required for a Yocto Project built kernel.

NOTE: kernel version is 3.0+
$ cat base/base.scc | head -n 1
set_kernel_version 2.6.37


FYI: nothing uses this at the moment. But I fixed that here.



There are three patches in standard, only two of which (the perf ones)
are listed in the standard.scc. As I believe any kernel we build should
have these, I would like to see any global patches applied to base,
leaving standard to define policy, and include named features.


standard only includes 3 patches because they were a bit hard to
classify elsewhere. In a more fully populated kernel, it does include
quite a bit more directly.


Sorry for the slow reply, I got bogged down trying to write some
python code yesterday.



directly = git repository commits?



Sort of. Or what I meant by directly was the "patch " right
in standard.scc. As you well know, for the most part, standard pulls in
patches by including other features, and those are just as direct
as a patch/commit listed right in the standard kernel .scc file.

The yocto kernels have thus far had relatively few additional features,
but if that changes, the standard kernel will have more direct changes
being applied to the branches.





With these changes, I could add ktypes/tiny as follows:
$ cat tiny/tiny.scc
include ktypes/base
branch tiny
include features/xyz/xyz.scc
include cfg/abc.scc

Another point of interest is preempt-rt, as I can see people wanting to
build tiny preempt-rt. I think the best approach here is to create
ktypes/tiny/preempt-rt-tiny/preempt-rt-tiny.scc.

Note: I believe this fails with .patch.patch
$ cat features/rt/rt.scc | grep patch
patch rt-apply-patch-3.0.10-rt27.patch.patch


Love my "patch.patch". Script went wild on that one, luckily the content
in the branch is king :) I fixed that here when I was auditing 3.0.12+rt
so that looks more sane now.



I'm working on a patch series that implements the suggestions I've made
above. Bruce, do you have any issues with this approach?


Allow me to ramble a bit below ...

No big issues. At some level(s) it is just a shell game. We can move
configs and patches around to the appropriate level to get the building
blocks that we need and get common functionality into a common location.

base was (is) intended to document the branch point from the mainline
kernel, and contain largely configuration and very few patches. Any
important or larger size functional additions go into the standard
kernel.


What is the value of having base and standard as separate branches?
Isn't base easily derivable from the standard git history? Still if it
isn't used anywhere, then the branch is a no-op and adds no complexity,
so that's fine.


base can definitely be derived from git history, or via git merge-base,
but the branch is a very clear delineation of the jumping point
and contains things like the initial commits to .gitignore. It also
provides a common branch point for the meta branch and standard, so
really basic things can be shared. It has also been used in the past
for a simple branch to build the stock korg ke

Re: [yocto] linux-yocto: ktypes/tiny and some questions along the way

[Bruce Ashfield]

On 11-12-14 01:07 PM, Darren Hart wrote:



On 12/14/2011 08:59 AM, Bruce Ashfield wrote:

On 11-12-12 06:17 PM, Darren Hart wrote:

On 12/11/2011 09:14 PM, Bruce Ashfield wrote:

On 11-12-09 5:52 PM, Darren Hart wrote:

Bruce,

I'm looking at introducing a new kernel type, ktypes/tiny.

Tiny will define a core set of kernel policy options, such as proc, sys,
devtmpfs, futex, epoll, elf bin format, etc. It will not enable any
drivers, filesystems, debug options, or networking options by default.
This would be the responsibility of the BSP to add a named feature
implementing this.

Taking a look at the ktypes we have now resulted in some questions:

dvhart@envy:~/source/linux/linux-yocto-3.0/meta/cfg/kernel-cache/ktypes
$ tree
.
├── base
│   ├── base.cfg
│   ├── base.scc
│   ├── hardware.cfg
│   ├── hardware.kcf
│   ├── non-hardware.cfg
│   └── non-hardware.kcf
├── preempt-rt
│   ├── preempt-rt.cfg
│   └── preempt-rt.scc
├── standard
│   ├── perf-force-include-of-stdbool.h.patch
│   ├── perf-hard-code-NO_LIBPERL-NO_LIBPYTHON.patch
│   ├── standard-patches.scc
│   ├── standard.cfg
│   ├── standard.scc
│   └── x86-add-TIF_32BIT-compatibility-define.patch

These form a hiearchy, each inheriting from the layer beneath like so:

base/standard/preempt-rt

As I dig into this I see that some policy is infact laid down by base,
including things like:

CONFIG_MODULES=y
CONFIG_INET=y
CONFIG_PREEMPT=y
CONFIG_NFS_FS=y
CONFIG_MSDOS_PARTITION=y

These pull in the IP stack, the block layer, etc. Because of this, I
can't really inherit from base for ktypes/tiny. I would like to inherit
the hardware and non-hardware kcf files though, as well as any patches
that might make their way into base. Which leads me to standard. I would
like to see a much smaller set of config policy options set in base.
Most likely these should be exactly what we agree on for tiny, and tiny
wouldn't add any additional policy as it implements only what is
required for a Yocto Project built kernel.

NOTE: kernel version is 3.0+
$ cat base/base.scc | head -n 1
set_kernel_version 2.6.37


FYI: nothing uses this at the moment. But I fixed that here.



There are three patches in standard, only two of which (the perf ones)
are listed in the standard.scc. As I believe any kernel we build should
have these, I would like to see any global patches applied to base,
leaving standard to define policy, and include named features.


standard only includes 3 patches because they were a bit hard to
classify elsewhere. In a more fully populated kernel, it does include
quite a bit more directly.


Sorry for the slow reply, I got bogged down trying to write some
python code yesterday.



directly = git repository commits?



Sort of. Or what I meant by directly was the "patch" right
in standard.scc. As you well know, for the most part, standard pulls in
patches by including other features, and those are just as direct
as a patch/commit listed right in the standard kernel .scc file.

The yocto kernels have thus far had relatively few additional features,
but if that changes, the standard kernel will have more direct changes
being applied to the branches.



I'm seeing a problem with the coupling of patches and configs. I
understand why it made sense to do at the time, but if we want to base
all branches off the same sources (and it's clear we do) then our
infrastructure should allow us to prepare that source base separately
from the config. Applying the config and then clearing it out is a
rather ugly solution IMO.


There are configs that absolutely should be coupled with patches,
and configs that don't need to be. We are obviously talking about
configs that don't need to be, and we definitely have the flexibility
to keep them apart.










With these changes, I could add ktypes/tiny as follows:
$ cat tiny/tiny.scc
include ktypes/base
branch tiny
include features/xyz/xyz.scc
include cfg/abc.scc

Another point of interest is preempt-rt, as I can see people wanting to
build tiny preempt-rt. I think the best approach here is to create
ktypes/tiny/preempt-rt-tiny/preempt-rt-tiny.scc.

Note: I believe this fails with .patch.patch
$ cat features/rt/rt.scc | grep patch
patch rt-apply-patch-3.0.10-rt27.patch.patch


Love my "patch.patch". Script went wild on that one, luckily the content
in the branch is king :) I fixed that here when I was auditing 3.0.12+rt
so that looks more sane now.



I'm working on a patch series that implements the suggestions I've made
above. Bruce, do you have any issues with this approach?


Allow me to ramble a bit below ...

No big issues. At some level(s) it is just a shell game. We can move
configs and patches around to the appropriate level to get the building
blocks that we need and get common functionality into a common location.

base was (is) intended to document the branch point from the mainline
kernel, and contain largely configuration and very few patches. Any
i

Re: [yocto] linux-yocto: ktypes/tiny and some questions along the way

[Bruce Ashfield]

On 11-12-14 02:06 PM, Darren Hart wrote:

On 12/14/2011 10:43 AM, Bruce Ashfield wrote:

On 11-12-14 01:07 PM, Darren Hart wrote:


Heavily trimmed down to the remaining points of discussion...


Everyone thanks you. I thought of doing that as well on my
last reply.




So what does that mean here? Well, I suggest we put all the sources in
standard (minus evil BSP patches obviously) and then create a ktype per
DISTRO definition:


And minus -rt at the moment.


Yes, sorry, I intended that, but didn't make that clear. Agreed.



yocto/base
yocto/standard/base
yocto/standard/poky
yocto/standard/poky-rt
yocto/standard/poky-tiny


I'd want the distro not to be named in the branches, but yes,
that looks ok to me.


Hrm, that's too bad. I really like the explicit coupling of the OE
distro definition to the linux-yocto branch. It helps reinforce the
concept of distro defined policy. I think I know where you are coming
from though.


I'm just thinking of re-use of the tree in other situations. i.e.
hypothetical OSV uses the tree and says "they are based on yocto",
and create their own distro. Having poky show up in branch names
would confuse that message .. and no one needs anyone else more
confused then they have to be.




Yep, I'm not sold on a distro name, but if you change this to:

yocto/base
yocto/standard/cfg (bad name, but I wanted something)
yocto/standard/rt
yocto/standard/tiny


How about:
 yocto/base
 yocto/standard/default
 yocto/standard/rt
 yocto/standard/tiny

"default" makes sense to me since, well, it is what we would use as the
default if no specification in made. Also, it's a shorter way of saying
"general purpose", which describes this policy/config fairly well.


Agreed. I'm ok with this. Naming things sucks.




Then the tree is more of a common base ... they are just names after
all! We already have 'yocto' in there, so that's enough specifics for
my taste.

or we flip it around ...

 base
 standard/yocto
 standard/yocto-rt
 standard/yocto-tiny

Which looks more like what you proposed, but without the double
specific names.


It's less typing! I like less typing. But if we're going to do that, why
not:

  base
  standard/poky
  standard/poky-rt
  standard/poky-tiny

If you would prefer to keep the branches build-system/distro agnostic,
then I think the ideal would be:


  base
  standard/default
  standard/rt
  standard/tiny

And, it's even LESS typing! Fingers, wrists, and keyboards everywhere
will be thanking us. ;-)


Will tell them to use TAB completion!! :)

I could go all the way down to this, I initially chose 'ycoto' because
it seemed like the right thing to do. But the tree already has yocto
in the name, and it's associated with the yocto project .. so really,
we don't need it in the branch names :) There's no plan merge multiple
different project baseline configs so the yocto designation is redundant.

.. I think we are almost there now. I could absolutely construct the
3.2 dev kernel to have these branches, and we'd leave existing trees
untouched.

But I'll let this debounce for a bit before heading down the garden
path :)

Cheers,

Bruce






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

Re: [yocto] [V2 PATCH 1/1] remove usbgadget from routerstationpro

[Bruce Ashfield]

On 11-12-14 8:02 PM, Zumeng Chen wrote:

   Since the target doesn't have the related requirement
   to use USB slave hardware supporting usb gadget, so
   remove it from MACHINE_FEATURES.


Indention went a bit out of whack there, but the wording is what
we want.

Acked-by: Bruce Ashfield 




Signed-off-by: zumeng.c...@windriver.com>
---
  meta-yocto/conf/machine/routerstationpro.conf |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta-yocto/conf/machine/routerstationpro.conf 
b/meta-yocto/conf/machine/routerstationpro.conf
index 9338ca1..52124d9 100644
--- a/meta-yocto/conf/machine/routerstationpro.conf
+++ b/meta-yocto/conf/machine/routerstationpro.conf
@@ -5,7 +5,7 @@
  require conf/machine/include/tune-mips32.inc

  MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 \
-serial usbgadget"
+serial"

  KERNEL_IMAGETYPE = "vmlinux"
  KERNEL_ALT_IMAGETYPE = "vmlinux.bin"


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

Re: [yocto] [PATCH 0/1][KERNEL] meta: Add cedartrail: Corrected machine branch name

[Bruce Ashfield]

On 11-12-14 7:54 PM, Saxena, Rahul wrote:

I made a mistake in specifying the machine branch name:


The new machine branch should be:

"yocto/standard/cedartrail"

instead of

  "yocto/standard/cedartview"

Sorry about that.


No problem at all. I read the right thing even if you didn't
type it :)

This looks fine to me, I'll queue it up ASAP.

Bruce



Thanks
Rahul

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of rahul.sax...@intel.com
Sent: Wednesday, December 14, 2011 9:28 AM
To: yocto@yoctoproject.org; bruce.ashfi...@windriver.com
Subject: [yocto] [PATCH 0/1][KERNEL] meta: Add cedartrail

From: Rahul Saxena

This is the initial version of a BSP for the Cedar Trail platform.
The Cedar Trail platform consists of the Intel Cedarview Atom processor
and Tiger Point Chipset.  I have succesfully booted Sato image on Cedar Trail
CRB, desktop and mobile pre-production sample boards and tested features
such as wired networking, VESA graphics, SATA, USB ports

Please pull into linux-yocto-3.0/meta and linux-yocto-dev/meta

Also, please create a new "yocto/standard/cedarview" machine branch in each
of the above, based on yocto/standard/base.

Thanks
Rahul

Signed=off-by: Rahul Saxena
---

The following changes since commit caa74f86f42f6ecc22c3e9f380176b2695579e18:
   Darren Hart (1):
 Add EFI scc and cfg files

are available in the git repository at:

   git://git.yoctoproject.org/linux-yocto-2.6.37-contrib rsaxena/meta-cedartrail
   
http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=rsaxena/meta-cedartrail

Rahul Saxena (1):
   meta: Add cedartrail Signed-off-by: Rahul Saxena
 

  .../bsp/cedartrail/cedartrail-preempt-rt.scc   |7 +++
  .../bsp/cedartrail/cedartrail-standard.scc |7 +++
  .../cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg |   58 
  .../cfg/kernel-cache/bsp/cedartrail/cedartrail.scc |   17 ++
  4 files changed, 89 insertions(+), 0 deletions(-)
  create mode 100755 
meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-preempt-rt.scc
  create mode 100755 
meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc
  create mode 100755 meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.cfg
  create mode 100755 meta/cfg/kernel-cache/bsp/cedartrail/cedartrail.scc

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


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

Re: [yocto] Raspberry Pi

[Bruce Ashfield]

On 11-12-15 5:23 PM, Richard Purdie wrote:

On Thu, 2011-12-15 at 21:47 +, Chris Tapp wrote:

Is anyone on this list considering (or working on) a BSP for the
Raspberry Pi (http://www.raspberrypi.org/faqs) ?

For those that haven't seen it, it's a credit-card sized 'home pc'
aimed primarily at educational users that includes a 700MHz ARM11
core, HDMI, OpenGL ES 2.0, ethernet and audio for about $35. It will
be supporting Debian, Fedora and ArchLinux at launch.

Looks like a good board for people that want to get in to Yocto /
embedded linux. Also looks like it's a good platform for some of my
stuff...

I would be interested in working on a BSP / distro if anyone is
working on it or would like to work on it.


I'm not aware of anyone working on this but I like the idea of a BSP for
it and it shouldn't be too hard to do. I'd be happy to ensure we have a
repository somewhere on git.yoctoproject.org to support this (and any
other similar BSP efforts) if that would help?


We can also help here @ Wind River. This board is one that's on my short
list for the BSP refresh covered by:

http://bugzilla.pokylinux.org/show_bug.cgi?id=1634

So I'd like to see it right in the yocto kernel as a hardware reference
platform.

I'm about to finalize a suggested list of boards and after that, we can
see what resources/people want to collaborate on some BSPs.

Cheers,

Bruce



Cheers,

Richard

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


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

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bruce Ashfield]

On 11-12-16 02:27 PM, Bodke, Kishore K wrote:

Hi,
Just wanted to know if this got fixed?
Everytime I give the build I have to cerry-pick the patches.


I sent a patch that modified the SRCREV of the base kern-tools
package to make the SRCREV modifiable by a layer. Did you try
that ?


But even after applying the patches, the build went through, but the image does 
not boot.


Darren might comment on that.

Bruce



Thanks
Kishore.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Wednesday, December 14, 2011 6:07 AM
To: Hart, Darren
Cc: Bodke, Kishore K; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 11-12-14 12:47 AM, Darren Hart wrote:

On 12/13/2011 09:13 PM, Bruce Ashfield wrote:

On 11-12-13 6:26 PM, Bodke, Kishore K wrote:

Yes.
Its with poky Edison with poky-extras/meta-kernel-dev master branch I am using 
for my build.


This is likely the problem. I use and test meta-kernel-dev everyday,
but that's always against master. I keep them in lockstep, since
meta-kernel-dev never really 'releases'.

That being said, we can figure out a combination that works. The
best thing to do, would be to remove the kern-tools-native bbappend
from your meta-kernel-dev layer (for now). You don't want the new
tools.


That won't work.  He is using the latest kernel which has needs
merge_config.sh - as I ran into myself last week. I had Kishore


There's still a way it will work, merge_config.sh is only ever
called from the kern-tools. There shouldn't be any non kern-tools
calls to merge_config.sh, the error:

   mv: cannot stat
   `/usr/local/src/yocto_1_1_release/poky/build1/tmp/work/crystalforest-
poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
   No such file or directory

Could only come from using the latest configme script from the
kern-tools. So *something* newer than any SRCREV found on the
edison branch is being used there.


cherry-pick the last two patches to kern-tools-native from master and
that got things going for him. So again, the question is: Why didn't the
kern-tools-native bbappend do that for him?


Aha. I may know the answer to that. The meta variant of the recipe looks
to assign the SRCREV in a way that the bbappend can't change. I did
this change during the day, but completely forgot when sending the
email. Can someone try this to see if it's the fix ?

index fb66211..bc9a6b9 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,8 +4,8 @@ LIC_FILES_CHKSUM =
"file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8

   DEPENDS = "git-native guilt-native"

-SRCREV = "eb3ed64cea80d23ffb28dfeaeb02cdfe3fb29340"
-PR = r12
+SRCREV ?= "eb3ed64cea80d23ffb28dfeaeb02cdfe3fb29340"
+PR = r13
   PV = "0.1+git${SRCPV}"

.. and Then I'll do a pull request.

But as to why it's happening, I have no idea, autorev should pick it
up. That's down in the guts of bitbake, and for some reason the old
downloaded variant doesn't seem to be updating.

Bruce



--
Darren



If that doesn't fix the problem, look for merge_log.txt in your
linux/meta/cfg/ directory structure and that will tell us exactly
what is going wrong.

Bruce



Thanks
Kishore.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Tuesday, December 13, 2011 3:25 PM
To: Bodke, Kishore K
Cc: Hart, Darren; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 11-12-13 6:17 PM, Bodke, Kishore K wrote:

Yeah.  I am using local bare clone for the linux-yocto-3.0 and using 
poky-extras/meta-kernel-dev in my bblayers.conf for my build.
Sorry for not mentioning this before.


Aha. This is completely different then. As Darren mentioned, the bbappend
should be getting the latest tools, I can look into that.

But to be clear, is this an edison branch + meta-kernel-dev ? That
will cause problems at some point (and I'm not sure if that is what
is happening here yet), since recipe updates to use the new tools
wouldn't be reflected in that branch while you are fed the new tools.

Cheers,

Bruce



Thanks
Kishore.

-Original Message-
From: Hart, Darren
Sent: Tuesday, December 13, 2011 3:15 PM
To: Bruce Ashfield
Cc: Bodke, Kishore K; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 12/13/2011 03:05 PM, Bruce Ashfield wrote:

On 11-12-13 5:50 PM, Bodke, Kishore K wrote:

Hi,

I get failure for the linux-yoctort_3.0.bb file for the poky Edison branch.

Darren told that it was fixed and merged to master.


This shouldn't be happening on edison at all. The 

Re: [yocto] [PATCH][meta-kernel-dev] kern-tools: Include do_install() in bbappend

[Bruce Ashfield]

On 11-12-16 8:31 PM, Darren Hart wrote:

do_install() has changed over versions of kern-tools, ensure this matches
the latest sources as referenced by ${AUTOREV}. Without this, using
this bbappend against older kern-tools recipes will fail in very strange
and unexplainable ways. The edison recipe for example has:

do_install() {
 install -d ${D}${bindir}
 for s in ${kern_tools_LIST}; do
 install -m 0755 ${S}/git/tools/$s ${D}${bindir}
 done
}


We don't need this. As I mentioned in other email, meta-kernel-dev
works with master, not any particular branch.

Removing this bbappend is the right solution if you aren't on master.

Having this in the bbappend, simply means that when I change the install
next time .. this breaks again.

Bruce



This resulted in do_kernel_configme failures:

| mv: cannot stat 
`/usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
 No such file or directory

Signed-off-by: Darren Hart
CC: Kishore Bodke
---
  .../kern-tools-native_git.bbappend |7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)

diff --git 
a/meta-kernel-dev/recipes-kernel/kern-tools-native/kern-tools-native_git.bbappend
 
b/meta-kernel-dev/recipes-kernel/kern-tools-native/kern-tools-native_git.bbappend
index 201ec7f..445b385 100644
--- 
a/meta-kernel-dev/recipes-kernel/kern-tools-native/kern-tools-native_git.bbappend
+++ 
b/meta-kernel-dev/recipes-kernel/kern-tools-native/kern-tools-native_git.bbappend
@@ -5,3 +5,10 @@ LOCALCOUNT = "0"
  # For local kern-tools work, fill in KERN_TOOLS_SRC and uncomment the SRC_URI
  # KERN_TOOLS_SRC ?= /path/to/local/kern-tools-clone
  # SRC_URI = "git://${KERN_TOOLS_SRC}"
+
+# This step has changed over versions of kern-tools, ensure this matches
+# the latest sources as referenced by ${AUTOREV}
+do_install() {
+   cd ${S}/git
+   make DESTDIR=${D}${bindir} install
+}


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

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bruce Ashfield]

On 11-12-16 8:34 PM, Darren Hart wrote:

On 12/16/2011 05:22 PM, Bodke, Kishore K wrote:


With the attached Darren's kern-tools-native_git.bb file, build was success.
Thanks
Kishore.


See the patch I just sent:kern-tools: Include do_install() in bbappend
for what I believe to be the solution.

I suppose the proper solution would be to version the kern-tools-native
recipe when major things like that change, but given the nature of this
layer, I think the above patch is adequate.


That's not the solution to either problem (well, yes, it's a solution
and there's nothing inherently wrong with it, it's just covering up
the underlying issue) which is a layer dependency issue. In this case,
meta-kernel-dev tracks the master branch of poky, not any other branch
or version. And that is implicit, not explicit, hence why it got into
this tangle.

We could simply branch meta-kernel-dev and have an edison branch for
it, not modify the appends to contain something that will just break
again in the future.

But meta-kernel-dev isn't officially used by much at the moment, so
I'm not convinced that branching it is worth the trouble (but I can
be convinced otherwise). I'd rather either just remove the kern-tools
bbappend (I'm probably the only one on the planet that really needs
it), or just trust people to know what they are up to with the
meta-kernel-dev layer.

Alternatively, we wait for layer dependency tooling and use that :)

Cheers,

Bruce



--
Darren



-Original Message-
From: Bodke, Kishore K
Sent: Friday, December 16, 2011 5:07 PM
To: Hart, Darren
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: RE: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

Hi,
I still get the same error below after changing the kern-tools-native_git.bb 
file.

SRCREV ?= "364437739c45a5e771d1f7b3ac73c35f1328fd97"
PR = r11


ERROR: Function 'do_kernel_configme' failed (see 
/usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.27942
 for further information)
ERROR: Logfile of failure stored in: 
/usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.27942
Log data follows:
| [INFO] doing kernel configme
| [INFO] Branch yocto/standard/preempt-rt/base used by common-pc-preempt-rt.scc
| [INFO] collecting configs in ./meta/meta-series
| mv: cannot stat 
`/usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
 No such file or directory
| creation of pre-processed config data failed
| config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed
| ERROR: Function 'do_kernel_configme' failed (see 
/usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.27942
 for further information)
NOTE: package 
linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
 task do_kernel_configme: Failed
NOTE: package gcc-cross-4.6.1+svnr175454-r10: task do_configure: Started
ERROR: Task 716 
(/usr/local/src/yocto_1_1/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb, 
do_kernel_configme) failed with exit code '1'

Thanks
Kishore.

-Original Message-
From: Hart, Darren
Sent: Friday, December 16, 2011 3:08 PM
To: Bodke, Kishore K
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 12/16/2011 02:12 PM, Bodke, Kishore K wrote:

I am building core-image-sato.
I have not changed any boot parameters.
Everything was default settings.


By image format I mean are you using a live image?
core-image-sato-*.hddimg or are you formatting a disk and copying over
contents of the rootfs? The kernel parameters are specified in
meta-intel and meta-romley.

My guess is something has gone wrong in the kernel config and the kernel
you built is missing things like vfat, ramfs support, etc.

Can you make your .config available as well as the various log.do* from
the linux-yocto temp directory and the meta-series from the linux source
directory?

--
Darren



Thanks
Kishore.

-Original Message-
From: Hart, Darren
Sent: Friday, December 16, 2011 12:18 PM
To: Bodke, Kishore K
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 12/16/2011 11:39 AM, Bodke, Kishore K wrote:

I will try

Re: [yocto] [PATCH 0/1] Example meta-intel poky-tiny support for fri2

[Bruce Ashfield]

On 11-12-21 04:09 AM, Darren Hart wrote:

This patch adds a similar linux-yocto-tiny recipe for fri2 that
my poky-tiny patch provides for qemux86. This one adds the necessary
bits to boot poky-tiny on fri2. The kernel increases in size by some
200k to accomodate the EFI, EG20T, and USB support. As with qemux86,
these fragments will be removed in favor of those provided in-tree
by the 3.2 linux-yocto kernel when it becomes available.


Looks good to me, and the 3.2 kernel re-branched, re-named,
optional + required configs are coming along nicely now, so we
should have test branches for merging the two right at the
beginning of January.

Cheers,

Bruce





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

Re: [yocto] [PATCH 4/9] linux-yocto-tiny: New kernel recipe for poky-tiny distro (INCOMPLETE)

[Bruce Ashfield]

On 11-12-21 04:02 AM, Darren Hart wrote:

linux-yocto-tiny drops the linux-tools and sets the KMACHINE
branch to standard/tiny.

Signed-off-by: Darren Hart
---
  meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg |9 +
  .../recipes-kernel/linux/linux-yocto-tiny/core.cfg |   19 +
  .../linux/linux-yocto-tiny/debug.cfg   |5 +
  .../linux/linux-yocto-tiny/devtmpfs.cfg|6 +
  .../linux/linux-yocto-tiny/e1000.cfg   |7 +
  .../recipes-kernel/linux/linux-yocto-tiny/ext2.cfg |1 +
  .../recipes-kernel/linux/linux-yocto-tiny/ext3.cfg |2 +
  .../recipes-kernel/linux/linux-yocto-tiny/lzma.cfg |3 +
  meta/recipes-kernel/linux/linux-yocto-tiny/net.cfg |   26 +
  .../linux/linux-yocto-tiny/qemux86/defconfig   |  613 
  .../linux/linux-yocto-tiny/ramfs.cfg   |6 +
  .../linux/linux-yocto-tiny/rtc-pc.cfg  |   13 +
  .../linux/linux-yocto-tiny/serial.cfg  |7 +
  meta/recipes-kernel/linux/linux-yocto-tiny/smp.cfg |7 +
  meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb  |   36 ++
  15 files changed, 760 insertions(+), 0 deletions(-)
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ext2.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ext3.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/lzma.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/net.cfg
  create mode 100644 
meta/recipes-kernel/linux/linux-yocto-tiny/qemux86/defconfig
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ramfs.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/rtc-pc.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/serial.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/smp.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb

diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg
new file mode 100644
index 000..97e4d00
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg
@@ -0,0 +1,9 @@
+# IDE disk support
+# Dependencies
+CONFIG_PCI=y
+CONFIG_BLOCK=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_ATA_SFF=y
+CONFIG_ATA_BMDMA=y
+CONFIG_ATA_PIIX=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg
new file mode 100644
index 000..7057218
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg
@@ -0,0 +1,19 @@
+# Basic facilities that shall be present in all kernels
+
+# Needed to execute... anything (like init)
+CONFIG_BINFMT_ELF=y
+
+# Needed by at least the telephony daemon
+CONFIG_SIGNALFD=y
+
+# At least bootlogd requires this
+CONFIG_UNIX98_PTYS=y
+
+# Required for basic IPC and pthread locking support
+CONFIG_SYSVIPC=y
+CONFIG_FUTEX=y
+CONFIG_RT_MUTEXES=y
+
+CONFIG_PROC_FS=y
+CONFIG_SYSFS=y
+
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg
new file mode 100644
index 000..886bfd9
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg
@@ -0,0 +1,5 @@
+# Debug options
+# +98k bzImage
+CONFIG_PRINTK=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_PRINTK_TIME=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg
new file mode 100644
index 000..07632e2
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg
@@ -0,0 +1,6 @@
+# For /dev and udev
+# Could eliminate for a static /dev tree
+# +1.5k bzImage
+CONFIG_HOTPLUG=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg
new file mode 100644
index 000..8e18bbb
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg
@@ -0,0 +1,7 @@
+# e1000 PCI network card support (qemu default)
+# FIXME: This appears in dmesg, but a probe fails
+# bzImage +31k
+CONFIG_PCI=y
+CONFIG_NETDEVICES=y
+CONFIG_NETDEV_1000=y
+CONFIG_E1000=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/ext2.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/ext2.cfg
new file mode 100644
index 000..e35c36d
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/ext2.cfg
@@ -0,0 +1 @@
+CONFIG_EXT2_FS=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/ext3.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/ext3.cfg
new file mode 100644
index 000..df9dd64
--- /dev/null
+++ b/meta/recipes-

Re: [yocto] [PATCH 1/1] mm: msync: fix the behaviour msync on tmpfs

[Bruce Ashfield]

On 11-12-21 10:24 AM, zumeng.chen wrote:

This patch has been validated by the following commands
on both CPUs with or without cache alias, which is for

http://bugzilla.pokylinux.org/show_bug.cgi?id=1429


Glad to see this. I was composing an email that had just this
question. Which bug, and which kernel version is the issue.



root@routerstationpro:~# dmesg|grep alias
Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
root@routerstationpro:~# for i in `seq 1 1000`; do ./msync01 ;done


root@localhost:/tmp> dmesg|grep alias
Primary data cache 32kB, 4-way, PIPT, no aliases, linesize 32 bytes
root@localhost:/tmp> zcat /proc/config.gz |grep WINPATH
CONFIG_WINTEGRA_WINPATH=y
CONFIG_WINTEGRA_WINPATH3=y
CONFIG_SERIAL_8250_WINPATH=y
root@localhost:/tmp> for i in `seq 1 1000`; do ./msync01 ;done

Passed.

On 2011年12月21日 23:17, Zumeng Chen wrote:

For tmpfs, no matter which flag(ASYNC or SYNC) gets from msync,
there is not so much thing to do for CPUs without cache alias,
But for some CPUs with cache alias, msync has to flush cache
explicitly, which makes sure the data coherency between memory
file and cache.


Is it just coherency, or are there corruption concerns as well ?

In the commit message, it would be useful to put an example
interaction that can trigger this issue, since it isn't entirely
obvious from the message. More information is always better.

Is this for the 3.0 and 2.6.37 kernels .. or just one, or the
other ?




Signed-off-by: Zumeng Chen
---
include/linux/mm.h | 1 +
mm/msync.c | 20 +++-
mm/shmem.c | 5 +
3 files changed, 25 insertions(+), 1 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index f59179b..858db90 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -868,6 +868,7 @@ extern void pagefault_out_of_memory(void);
extern void show_free_areas(unsigned int flags);
extern bool skip_free_areas_node(unsigned int flags, int nid);

+int is_shmem_file(struct file *file);


If there aren't any more users of this other than your
msync.c below, we shouldn't need this exposed in mm.h. I
realized that it is implemented in shmem.c, but isn't there
a less global place to add this export (consider mm/internal.h)?
Also shouldn't it be extern, like the other defines in the file ?


int shmem_lock(struct file *file, int lock, struct user_struct *user);
struct file *shmem_file_setup(const char *name, loff_t size, unsigned
long flags);
void shmem_set_file(struct vm_area_struct *vma, struct file *file);
diff --git a/mm/msync.c b/mm/msync.c
index 632df45..2f0d8fa 100644
--- a/mm/msync.c
+++ b/mm/msync.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include

/*
* MS_SYNC syncs the entire file - including mappings.
@@ -33,6 +34,7 @@ SYSCALL_DEFINE3(msync, unsigned long, start, size_t,
len, int, flags)
unsigned long end;
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
+ struct file *file;
int unmapped_error = 0;
int error = -EINVAL;

@@ -56,8 +58,24 @@ SYSCALL_DEFINE3(msync, unsigned long, start,
size_t, len, int, flags)
*/
down_read(&mm->mmap_sem);
vma = find_vma(mm, start);
+
+#ifdef CONFIG_TMPFS
+ /*
+ * For tmpfs, no matter which flag(ASYNC or SYNC) gets from msync,
+ * there is not so much thing to do for CPUs without cache alias,
+ * But for some CPUs with cache alias, msync has to flush cache
+ * explicitly, which makes sure the data coherency between memory
+ * file and cache.
+ */
+ file = vma->vm_file;
+ if (is_shmem_file(file)) {
+ flush_cache_range(vma, start, start+len);
+ error = 0;


Hasn't error already been set to 0 ? .. I see it in the
original function being set right before this chunk of code
will run.


+ goto out_unlock;


Do we really want this for all architectures/all boards ? This
is common/global code, so we need to tread carefully.

Is there a way that we could do this by arch hooks .. or is
flush_cache_range() sufficiently benign that it is little overhead
and safe everywhere ?

In the end, I'm not a mm expert, so we can fix this up, think
about it, and then run it past the people that really know :)


+ }
+#endif
+
for (;;) {
- struct file *file;


There's an assignment:

  file = vma->vm_file;

Later in this routine, you've already done that above, so can't
it be dropped ?

Bruce



/* Still start< end. */
error = -ENOMEM;
diff --git a/mm/shmem.c b/mm/shmem.c
index 92e5c15..4fabfac 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2793,6 +2793,11 @@ static struct file_system_type tmpfs_fs_type = {
.kill_sb = kill_litter_super,
};

+int is_shmem_file(struct file *file)
+{
+ return (file->f_op ==&shmem_file_operations)? 1 : 0;
+}
+
int __init init_tmpfs(void)
{
int error;




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

Re: [yocto] [PATCH 4/9] linux-yocto-tiny: New kernel recipe for poky-tiny distro (INCOMPLETE)

[Bruce Ashfield]

On 11-12-21 10:52 AM, Darren Hart wrote:



On 12/21/2011 06:56 AM, Bruce Ashfield wrote:

On 11-12-21 04:02 AM, Darren Hart wrote:

linux-yocto-tiny drops the linux-tools and sets the KMACHINE
branch to standard/tiny.

Signed-off-by: Darren Hart
---
   meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg |9 +
   .../recipes-kernel/linux/linux-yocto-tiny/core.cfg |   19 +
   .../linux/linux-yocto-tiny/debug.cfg   |5 +
   .../linux/linux-yocto-tiny/devtmpfs.cfg|6 +
   .../linux/linux-yocto-tiny/e1000.cfg   |7 +
   .../recipes-kernel/linux/linux-yocto-tiny/ext2.cfg |1 +
   .../recipes-kernel/linux/linux-yocto-tiny/ext3.cfg |2 +
   .../recipes-kernel/linux/linux-yocto-tiny/lzma.cfg |3 +
   meta/recipes-kernel/linux/linux-yocto-tiny/net.cfg |   26 +
   .../linux/linux-yocto-tiny/qemux86/defconfig   |  613 

   .../linux/linux-yocto-tiny/ramfs.cfg   |6 +
   .../linux/linux-yocto-tiny/rtc-pc.cfg  |   13 +
   .../linux/linux-yocto-tiny/serial.cfg  |7 +
   meta/recipes-kernel/linux/linux-yocto-tiny/smp.cfg |7 +
   meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb  |   36 ++
   15 files changed, 760 insertions(+), 0 deletions(-)
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ext2.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ext3.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/lzma.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/net.cfg
   create mode 100644 
meta/recipes-kernel/linux/linux-yocto-tiny/qemux86/defconfig
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ramfs.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/rtc-pc.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/serial.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/smp.cfg
   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb

diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg
new file mode 100644
index 000..97e4d00
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg
@@ -0,0 +1,9 @@
+# IDE disk support
+# Dependencies
+CONFIG_PCI=y
+CONFIG_BLOCK=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_ATA_SFF=y
+CONFIG_ATA_BMDMA=y
+CONFIG_ATA_PIIX=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg
new file mode 100644
index 000..7057218
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg
@@ -0,0 +1,19 @@
+# Basic facilities that shall be present in all kernels
+
+# Needed to execute... anything (like init)
+CONFIG_BINFMT_ELF=y
+
+# Needed by at least the telephony daemon
+CONFIG_SIGNALFD=y
+
+# At least bootlogd requires this
+CONFIG_UNIX98_PTYS=y
+
+# Required for basic IPC and pthread locking support
+CONFIG_SYSVIPC=y
+CONFIG_FUTEX=y
+CONFIG_RT_MUTEXES=y
+
+CONFIG_PROC_FS=y
+CONFIG_SYSFS=y
+
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg
new file mode 100644
index 000..886bfd9
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg
@@ -0,0 +1,5 @@
+# Debug options
+# +98k bzImage
+CONFIG_PRINTK=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_PRINTK_TIME=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg
new file mode 100644
index 000..07632e2
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg
@@ -0,0 +1,6 @@
+# For /dev and udev
+# Could eliminate for a static /dev tree
+# +1.5k bzImage
+CONFIG_HOTPLUG=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg
new file mode 100644
index 000..8e18bbb
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg
@@ -0,0 +1,7 @@
+# e1000 PCI network card support (qemu default)
+# FIXME: This appears in dmesg, but a probe fails
+# bzImage +31k
+CONFIG_PCI=y
+CONFIG_NETDEVICES=y
+CONFIG_NETDEV_1000=y
+CONFIG_E1000=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/ext2.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/ext2.cfg
new file mode 100644
index 000..e35c36d
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/ext2.cfg
@@ -0,0 +1 @@
+CONFIG_EXT2_FS=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/ext3.cfg 
b/meta

Re: [yocto] [PATCH 4/9] linux-yocto-tiny: New kernel recipe for poky-tiny distro (INCOMPLETE)

[Bruce Ashfield]

On 11-12-21 11:02 AM, Darren Hart wrote:



On 12/21/2011 07:56 AM, Bruce Ashfield wrote:

On 11-12-21 10:52 AM, Darren Hart wrote:



On 12/21/2011 06:56 AM, Bruce Ashfield wrote:

On 11-12-21 04:02 AM, Darren Hart wrote:

linux-yocto-tiny drops the linux-tools and sets the KMACHINE
branch to standard/tiny.

Signed-off-by: Darren Hart
---


...


+SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta
 \
+   file://core.cfg \
+   file://serial.cfg \
+   file://ext2.cfg \
+   file://rtc-pc.cfg \
+   file://ramfs.cfg \
+   file://devtmpfs.cfg \
+   file://net.cfg \
+   file://debug.cfg \
+   file://lzma.cfg \
+   "


So I assume that the order of these doesn't really matter, and that
they are non-overlapping ? The answer must be yes, since you've been
testing this, and you don't have a .scc file to control their order :)



That's correct.


Other than that, it looks pretty good to me.


Great. Did you have a close look at core.cfg? It along with things like
devtmpfs and ramfs are likely to form the basis of the linux-yocto tiny
ktype general policy.


I had a 'medium' depth look :) I didn't see anything outrageous
or shocking. I'll loop back and have a better look later as well.


I'm mostly interested in things that are MISSING.


Aha. That's different. I'll go back and look!

Bruce





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

Re: [yocto] [PATCH 4/9] linux-yocto-tiny: New kernel recipe for poky-tiny distro (INCOMPLETE)

[Bruce Ashfield]

On 11-12-21 01:58 PM, Darren Hart wrote:

linux-yocto-tiny drops the linux-tools and sets the KMACHINE
branch to standard/tiny.

Signed-off-by: Darren Hart
---
  meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg |9 +
  .../recipes-kernel/linux/linux-yocto-tiny/core.cfg |   19 +
  .../linux/linux-yocto-tiny/debug.cfg   |5 +
  .../linux/linux-yocto-tiny/devtmpfs.cfg|6 +
  .../linux/linux-yocto-tiny/e1000.cfg   |7 +
  .../recipes-kernel/linux/linux-yocto-tiny/ext2.cfg |1 +
  .../recipes-kernel/linux/linux-yocto-tiny/ext3.cfg |2 +
  .../recipes-kernel/linux/linux-yocto-tiny/lzma.cfg |3 +
  meta/recipes-kernel/linux/linux-yocto-tiny/net.cfg |   26 +
  .../linux/linux-yocto-tiny/qemux86/defconfig   |  613 
  .../linux/linux-yocto-tiny/ramfs.cfg   |6 +
  .../linux/linux-yocto-tiny/rtc-pc.cfg  |   13 +
  .../linux/linux-yocto-tiny/serial.cfg  |7 +
  meta/recipes-kernel/linux/linux-yocto-tiny/smp.cfg |7 +
  meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb  |   36 ++
  15 files changed, 760 insertions(+), 0 deletions(-)
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ext2.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ext3.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/lzma.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/net.cfg
  create mode 100644 
meta/recipes-kernel/linux/linux-yocto-tiny/qemux86/defconfig
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/ramfs.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/rtc-pc.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/serial.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny/smp.cfg
  create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_3.0.bb

diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg
new file mode 100644
index 000..97e4d00
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/ata.cfg
@@ -0,0 +1,9 @@
+# IDE disk support
+# Dependencies
+CONFIG_PCI=y
+CONFIG_BLOCK=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_ATA_SFF=y
+CONFIG_ATA_BMDMA=y
+CONFIG_ATA_PIIX=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg
new file mode 100644
index 000..7057218
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/core.cfg
@@ -0,0 +1,19 @@
+# Basic facilities that shall be present in all kernels
+
+# Needed to execute... anything (like init)
+CONFIG_BINFMT_ELF=y
+
+# Needed by at least the telephony daemon
+CONFIG_SIGNALFD=y
+
+# At least bootlogd requires this
+CONFIG_UNIX98_PTYS=y
+
+# Required for basic IPC and pthread locking support
+CONFIG_SYSVIPC=y
+CONFIG_FUTEX=y
+CONFIG_RT_MUTEXES=y
+
+CONFIG_PROC_FS=y
+CONFIG_SYSFS=y
+
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg
new file mode 100644
index 000..886bfd9
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/debug.cfg
@@ -0,0 +1,5 @@
+# Debug options
+# +98k bzImage
+CONFIG_PRINTK=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_PRINTK_TIME=y


Taking the closer look that I promised. Did you build with printk
completely disabled ? It used to produce invalid images, so I was
curious to know if that has been fixed.

Anytime I see debug, I always think 'optional' (i.e. like the cfg/debug.cfg
that I've had in the past).

98k isn't much to add, but in a crunch, these could easily be made
optional.


diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg
new file mode 100644
index 000..07632e2
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/devtmpfs.cfg
@@ -0,0 +1,6 @@
+# For /dev and udev
+# Could eliminate for a static /dev tree
+# +1.5k bzImage
+CONFIG_HOTPLUG=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg 
b/meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg
new file mode 100644
index 000..8e18bbb
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny/e1000.cfg
@@ -0,0 +1,7 @@
+# e1000 PCI network card support (qemu default)
+# FIXME: This appears in dmesg, but a probe fails
+# bzImage +31k
+CONFIG_PCI=y
+CONFIG_NETDEVICES=y
+CONFIG_NETDEV_1000=y
+CONFIG_E1000=y
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny/ext2.cfg 
b/meta/recipes-kernel/linux/linux-yocto-

Re: [yocto] [V2 PATCH 1/1] mm: msync: fix issues of sys_msync on tmpfs

[Bruce Ashfield]

On 11-12-21 10:07 PM, Zumeng Chen wrote:

There are two problems as follows shown:
1 ) for TMPFS, nothing need to be done in sys_msync,
 sys_msync just return 0 for all arches.

2 ) But for MIPS CPUs with cache alias(dmesg|grep alias),
 it maybe has the issue, which reported by msync test
 suites in ltp-full, when the memory of memset used by
 msycn01 has cache alias.
 So, in this situation, we have to flush the related
 vma to make sure correct read.


Looks good. I'll queue this for the next kernel update.

Cheers,

Bruce



Signed-off-by: Zumeng Chen
---
  include/linux/shmem_fs.h |   10 ++
  mm/msync.c   |   22 +-
  mm/shmem.c   |5 +
  3 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
index aa08fa8..62a2d57 100644
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -12,6 +12,15 @@

  #define SHMEM_SYMLINK_INLINE_LEN (SHMEM_NR_DIRECT * sizeof(swp_entry_t))

+/*
+
+*/
+#ifndef cpu_has_dc_aliases
+#define CPU_HAS_CACHE_ALIAS 0
+#else
+#define CPU_HAS_CACHE_ALIAS cpu_has_dc_aliases
+#endif
+
  struct shmem_inode_info {
spinlock_t  lock;
unsigned long   flags;
@@ -49,6 +58,7 @@ static inline struct shmem_inode_info *SHMEM_I(struct inode 
*inode)
  /*
   * Functions in mm/shmem.c called directly from elsewhere:
   */
+extern int is_shmem_file(struct file *file);
  extern int init_tmpfs(void);
  extern int shmem_fill_super(struct super_block *sb, void *data, int silent);
  extern struct file *shmem_file_setup(const char *name,
diff --git a/mm/msync.c b/mm/msync.c
index 632df45..84cb068 100644
--- a/mm/msync.c
+++ b/mm/msync.c
@@ -13,6 +13,8 @@
  #include
  #include
  #include
+#include
+#include

  /*
   * MS_SYNC syncs the entire file - including mappings.
@@ -33,6 +35,7 @@ SYSCALL_DEFINE3(msync, unsigned long, start, size_t, len, 
int, flags)
unsigned long end;
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
+   struct file *file;
int unmapped_error = 0;
int error = -EINVAL;

@@ -56,8 +59,25 @@ SYSCALL_DEFINE3(msync, unsigned long, start, size_t, len, 
int, flags)
 */
down_read(&mm->mmap_sem);
vma = find_vma(mm, start);
+
+#ifdef CONFIG_TMPFS
+   /*
+* For tmpfs, no matter which flag(ASYNC or SYNC) gets from msync,
+* there is not so much thing to do for CPUs without cache alias,
+* But for some CPUs with cache alias, msync has to flush cache
+* explicitly, which makes sure the data coherency between memory
+* file and cache.
+*/
+   file =  vma->vm_file;
+   if (is_shmem_file(file)) {
+   if(CPU_HAS_CACHE_ALIAS)
+   flush_cache_range(vma, start, start+len);
+   error = 0;
+   goto out_unlock;
+   }
+#endif
+
for (;;) {
-   struct file *file;

/* Still start<  end. */
error = -ENOMEM;
diff --git a/mm/shmem.c b/mm/shmem.c
index 92e5c15..4fabfac 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2793,6 +2793,11 @@ static struct file_system_type tmpfs_fs_type = {
.kill_sb= kill_litter_super,
  };

+int is_shmem_file(struct file *file)
+{
+   return (file->f_op ==&shmem_file_operations)? 1 : 0;
+}
+
  int __init init_tmpfs(void)
  {
int error;


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

Re: [yocto] RFC: Yocto BSP and kernel usability tools

[Bruce Ashfield]

On 11-12-19 11:55 AM, Tom Zanussi wrote:

Hi,

This is what I hope to implement in the M2 timeframe.

Any and all comments welcome...

Thanks,

Tom

---

Getting Yocto running on a new board is often a prerequisite task to
the real task of interest for new users, which is creating new
applications designed to run on the board, or creating new
board-specific embedded systems.  In other words, most users just want
to get the hardware up and running and not have to think too much
about it before moving on to what they're really interested in, which
is the stuff running on top of it.

While there really can't be any such thing as a magic-bullet
application that would do that automatically i.e. generate and
maintain a guaranteed-working Yocto BSP for any given piece of
hardware, it should at least be possible to provide a tool that would
generate a base BSP usable as a starting point for that, and which
would additionally allow the user to tweak various BSP settings,
including kernel configuration options and simple kernel patches.
Such a tool should be usable with only a minimal understanding of the
Yocto build system and metadata, and with no knowledge at all of
kernel internals or the Yocto kernel recipe bindings, or of the
details of the internals of yocto kernel repositories, or in fact any
knowledge of git or any other specific build-related tool.

This document provides the design for such a tool.  At a high level,
the goal of the tool is to provide a user the means of creating a new
Yocto BSP from which it should be possible (assuming a perfect
run-time outcome, admittedly unlikely on a first pass) to submit a
'pull request' for inclusion into any repo(s) that would accept an
'official' Yocto BSP.  For example, the output of the tool should
produce metadata and kernel configuration that would be directly
mergeable into the meta-intel and the linux-yocto kernel repos.  The
tool should also allow the BSP maintainer to afterwards at any time
make changes to the kernel configuration and/or submit kernel patches
for the BSP.

Note that although knowledge of the Yocto kernel or kernel internals
is not expected, the user is expected to know the basics of how to
deal with the linux kernel at the 'user' level, specifically
understanding and determining the specific kernel config options
needed for the user's BSP.

Specifically, the tool will allow for the following high-level tasks,
which are discussed in more detail below:

- create a new BSP from scratch from a set of user-settable parameters
- manage individual kernel config settings
- create and use groups of kernel config settings as KERNEL_FEATUREs
- apply patches to a BSP's machine branch

The following capabilities are specifically not provided by the tool:

- help in determining a 'correct' set of kernel config options to set.
   The tool assumes the user already knows that, either through diffs
   of .config files before and after using 'bitbake -c menuconfig', or
   some other means.


Other means could also include the output of kconf_check. I could break
it out into something that could be iteratively run, if we think that
would be useful.



- modification of the BSP metadata after BSP creation.  The tool
   provides an initial 'write-once' BSP-generation capability, but
   doesn't allow it to be read in and modified after the initial pass.
   The user will have to make further modifications manually.  The one
   exception to this is kernel features, which can be added to an
   already existing kernel bbappend file.

- a guarantee or even expectation that the generated BSP will work on
   the actual hardware it's targeted for - it's highly unlikely the BSP
   will work 'out-of-the-box' and it's the developer's reponsibility to
   do the often hard work of figuring out what settings and/or code are
   actually needed to get the hardware to work as expected.  The goal
   of the tool is to make that job easier, not to actually do that job.

Also, though it's not explicitly a requirement of this tool, the
design should be sufficiently modular to allow for its participation
in generic logical pipelines.  For instance, while the tool may
present to the user a text-based UI for gathering information, it
should also be able to operate without any kind of user interaction
and retrieve the data it needs from a file, for instance e.g.:

  $ yocto-bsp create<  x86-input.json

Another example that the design should not preclude would be its use
at the end of a bsp-import pipeline e.g.:

  $ cat 3rdparty.bsp | 3rdparty2yocto | yocto-bsp create


Setting expectations! ;) That would be nice though.



The tool will initially be implemented as a set of command-line tools
which will essentially be thin layers on top of a modular Python API;
future tools may be GUI-based but would make use of the functionality
exposed through the same API.  There might also be an opportunity for
future integration into existing tools such as hob; this isn't
explicitly catered for in

Re: [yocto] meta-ti?????

[Bruce Ashfield]

On 11-12-23 08:10 AM, James Abernathy wrote:


On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote:



Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven:


On Friday 23 December 2011 09:28:31 Koen Kooi wrote:

Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven:

I know the examples in the documentation of Yocto use meta-intel a lot
to get the board specific BSPs like meta-crownbay or meta-n450.

Is there a meta-ti or similar that gets you the meta-beagleboard and
meta-pandaboard?  If not how do you clone and checkout the pandaboard
BPS?

http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/

It has a README in there on how to set it up, read it and follow it
precisely.


Just out of interest, why does meta-texasinstruments depend on meta-angstrom?


It needs extra things in overrides and reuses tasks from there.


Sorry for the follow-up, but if I clone the meta-texasinstruments bsp 
repository and checkout the pandaboard-rework branch,
how does that relate to the Yocto branch/bsp yocto/standard/pandaboard on the 
Yocto site?


I'll jump into the middle of the thread, and answer a couple of specific
questions and leave the larger what depends on what, and where
things evolve and why .. for another day.

The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update
of a reference BSP for the 3.0 (and newer) kernel(s).

But what you are seeing ,in the linux-yocto kernel tree, is a work in
progress at the moment, since there is an associated layer that is a
combo layer, and uses the layer tooling to build on top work that has
already been done by TI and other distro layers.

Since, as already been covered in this thread, there (often) multiple
places support for any  given board can be found. What you use, all
depends on what you are looking for.

The linux-yocto variant is built/tested with a yocto + oe-core base
and receives updates of features/fixes that other BSPs in the tree
gets. (note: I'm not claiming this is unique, just that it is done
using the yocto kernel tooling ). A common set of features and docs
would accompany any related BSPs. In this case, the BSP was contributed
to the project on the 3.0 kernel, so I merged it into the tree to
have that integrated support with as few layers as possible.

If you want the angstrom/TI pandaboard, doing what Koen suggests is
the ticket. Look at those layers, follow their READMEs and you'll be
good to go.

Cheers,

Bruce





Being a Yocto newbie, it's hard enough to understand all the branches on the 
yocto site. Relating the meta-angstrom is confusing.

The light bulb has now gone on yet :-)

Jim A


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


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


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

Re: [yocto] meta-ti?????

[Bruce Ashfield]

On 11-12-23 12:38 PM, Philip Balister wrote:

On 12/23/2011 12:10 PM, Bruce Ashfield wrote:

On 11-12-23 08:10 AM, James Abernathy wrote:


On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote:



Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven:


On Friday 23 December 2011 09:28:31 Koen Kooi wrote:

Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven:

I know the examples in the documentation of Yocto use meta-intel a
lot
to get the board specific BSPs like meta-crownbay or meta-n450.

Is there a meta-ti or similar that gets you the meta-beagleboard and
meta-pandaboard?  If not how do you clone and checkout the pandaboard
BPS?

http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/


It has a README in there on how to set it up, read it and follow it
precisely.


Just out of interest, why does meta-texasinstruments depend on
meta-angstrom?


It needs extra things in overrides and reuses tasks from there.


Sorry for the follow-up, but if I clone the meta-texasinstruments bsp
repository and checkout the pandaboard-rework branch,
how does that relate to the Yocto branch/bsp yocto/standard/pandaboard
on the Yocto site?


I'll jump into the middle of the thread, and answer a couple of specific
questions and leave the larger what depends on what, and where
things evolve and why .. for another day.

The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update
of a reference BSP for the 3.0 (and newer) kernel(s).


Who is the intended audience of this BSP? The Angstrom/meta-to layer is
obviously intended for people using TI hardware and all the associated
peripherals. Without defining your audience better, this jsut adds to
the confusion end users are experiencing with all the words and layers
being used in emails. This is becoming a real problem as new users enter
the project.


Quite simply, the audience that needs a particular kernel version
and feature set, with the tooling to transition to a supported (i.e
not the yocto one) BSP.

Cheers,

Bruce



Philip



But what you are seeing ,in the linux-yocto kernel tree, is a work in
progress at the moment, since there is an associated layer that is a
combo layer, and uses the layer tooling to build on top work that has
already been done by TI and other distro layers.

Since, as already been covered in this thread, there (often) multiple
places support for any  given board can be found. What you use, all
depends on what you are looking for.

The linux-yocto variant is built/tested with a yocto + oe-core base
and receives updates of features/fixes that other BSPs in the tree
gets. (note: I'm not claiming this is unique, just that it is done
using the yocto kernel tooling ). A common set of features and docs
would accompany any related BSPs. In this case, the BSP was contributed
to the project on the 3.0 kernel, so I merged it into the tree to
have that integrated support with as few layers as possible.

If you want the angstrom/TI pandaboard, doing what Koen suggests is
the ticket. Look at those layers, follow their READMEs and you'll be
good to go.

Cheers,

Bruce





Being a Yocto newbie, it's hard enough to understand all the branches
on the yocto site. Relating the meta-angstrom is confusing.

The light bulb has now gone on yet :-)

Jim A


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


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


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



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

Re: [yocto] meta-ti?????

[Bruce Ashfield]

On 11-12-23 12:52 PM, Koen Kooi wrote:


Op 23 dec. 2011, om 18:45 heeft Bruce Ashfield het volgende geschreven:


On 11-12-23 12:38 PM, Philip Balister wrote:

On 12/23/2011 12:10 PM, Bruce Ashfield wrote:

On 11-12-23 08:10 AM, James Abernathy wrote:


On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote:



Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven:


On Friday 23 December 2011 09:28:31 Koen Kooi wrote:

Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven:

I know the examples in the documentation of Yocto use meta-intel a
lot
to get the board specific BSPs like meta-crownbay or meta-n450.

Is there a meta-ti or similar that gets you the meta-beagleboard and
meta-pandaboard?  If not how do you clone and checkout the pandaboard
BPS?

http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/


It has a README in there on how to set it up, read it and follow it
precisely.


Just out of interest, why does meta-texasinstruments depend on
meta-angstrom?


It needs extra things in overrides and reuses tasks from there.


Sorry for the follow-up, but if I clone the meta-texasinstruments bsp
repository and checkout the pandaboard-rework branch,
how does that relate to the Yocto branch/bsp yocto/standard/pandaboard
on the Yocto site?


I'll jump into the middle of the thread, and answer a couple of specific
questions and leave the larger what depends on what, and where
things evolve and why .. for another day.

The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update
of a reference BSP for the 3.0 (and newer) kernel(s).


Who is the intended audience of this BSP? The Angstrom/meta-to layer is
obviously intended for people using TI hardware and all the associated
peripherals. Without defining your audience better, this jsut adds to
the confusion end users are experiencing with all the words and layers
being used in emails. This is becoming a real problem as new users enter
the project.


Quite simply, the audience that needs a particular kernel version
and feature set, with the tooling to transition to a supported (i.e
not the yocto one) BSP.


You do realize that by doing this without informing anyone involved with the official 
pandaboard BSP the net effect is negative? And by 'negative' I mean "severe 
annoyance" among other things.


.. and why would you assume that precisely that hadn't been done ?
It has been, via management channels at multiple companies and
organizations and is exactly why I said "a layer you can't get"
and "work in progress".

So please, no need to jump to anything resembling 'annoyance'.
There's plenty of that to go around, and it isn't constructive.

Bruce





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


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

Re: [yocto] [V2 PATCH 1/1] mm: msync: fix issues of sys_msync on tmpfs

[Bruce Ashfield]

On 12-01-03 11:53 PM, Khem Raj wrote:

On (22/12/11 09:24), Bruce Ashfield wrote:

On 11-12-21 10:07 PM, Zumeng Chen wrote:

There are two problems as follows shown:
1 ) for TMPFS, nothing need to be done in sys_msync,
 sys_msync just return 0 for all arches.

2 ) But for MIPS CPUs with cache alias(dmesg|grep alias),
 it maybe has the issue, which reported by msync test
 suites in ltp-full, when the memory of memset used by
 msycn01 has cache alias.
 So, in this situation, we have to flush the related
 vma to make sure correct read.


Looks good. I'll queue this for the next kernel update.




has this been proposed to lkml ?


Not yet. We are still reviewing it @ Wind River via our process, and
since we picked it up on MIPS, we are running it past Ralf as well.
Still time to get it in place for 3.3, if it is legit.

Cheers,

Bruce




Cheers,

Bruce



Signed-off-by: Zumeng Chen
---
  include/linux/shmem_fs.h |   10 ++
  mm/msync.c   |   22 +-
  mm/shmem.c   |5 +
  3 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
index aa08fa8..62a2d57 100644
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -12,6 +12,15 @@

  #define SHMEM_SYMLINK_INLINE_LEN (SHMEM_NR_DIRECT * sizeof(swp_entry_t))

+/*
+
+*/
+#ifndef cpu_has_dc_aliases
+#define CPU_HAS_CACHE_ALIAS 0
+#else
+#define CPU_HAS_CACHE_ALIAS cpu_has_dc_aliases
+#endif
+
  struct shmem_inode_info {
spinlock_t  lock;
unsigned long   flags;
@@ -49,6 +58,7 @@ static inline struct shmem_inode_info *SHMEM_I(struct inode 
*inode)
  /*
   * Functions in mm/shmem.c called directly from elsewhere:
   */
+extern int is_shmem_file(struct file *file);
  extern int init_tmpfs(void);
  extern int shmem_fill_super(struct super_block *sb, void *data, int silent);
  extern struct file *shmem_file_setup(const char *name,
diff --git a/mm/msync.c b/mm/msync.c
index 632df45..84cb068 100644
--- a/mm/msync.c
+++ b/mm/msync.c
@@ -13,6 +13,8 @@
  #include
  #include
  #include
+#include
+#include

  /*
   * MS_SYNC syncs the entire file - including mappings.
@@ -33,6 +35,7 @@ SYSCALL_DEFINE3(msync, unsigned long, start, size_t, len, 
int, flags)
unsigned long end;
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
+   struct file *file;
int unmapped_error = 0;
int error = -EINVAL;

@@ -56,8 +59,25 @@ SYSCALL_DEFINE3(msync, unsigned long, start, size_t, len, 
int, flags)
 */
down_read(&mm->mmap_sem);
vma = find_vma(mm, start);
+
+#ifdef CONFIG_TMPFS
+   /*
+* For tmpfs, no matter which flag(ASYNC or SYNC) gets from msync,
+* there is not so much thing to do for CPUs without cache alias,
+* But for some CPUs with cache alias, msync has to flush cache
+* explicitly, which makes sure the data coherency between memory
+* file and cache.
+*/
+   file =  vma->vm_file;
+   if (is_shmem_file(file)) {
+   if(CPU_HAS_CACHE_ALIAS)
+   flush_cache_range(vma, start, start+len);
+   error = 0;
+   goto out_unlock;
+   }
+#endif
+
for (;;) {
-   struct file *file;

/* Still start<   end. */
error = -ENOMEM;
diff --git a/mm/shmem.c b/mm/shmem.c
index 92e5c15..4fabfac 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2793,6 +2793,11 @@ static struct file_system_type tmpfs_fs_type = {
.kill_sb= kill_litter_super,
  };

+int is_shmem_file(struct file *file)
+{
+   return (file->f_op ==&shmem_file_operations)? 1 : 0;
+}
+
  int __init init_tmpfs(void)
  {
int error;


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




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

Re: [yocto] meta-ti?????

[Bruce Ashfield]

On 12-01-04 12:15 AM, Khem Raj wrote:

On (23/12/11 12:59), Bruce Ashfield wrote:

On 11-12-23 12:52 PM, Koen Kooi wrote:


Op 23 dec. 2011, om 18:45 heeft Bruce Ashfield het volgende geschreven:


On 11-12-23 12:38 PM, Philip Balister wrote:

On 12/23/2011 12:10 PM, Bruce Ashfield wrote:

On 11-12-23 08:10 AM, James Abernathy wrote:


On Dec 23, 2011, at 3:50 AM, Koen Kooi wrote:



Op 23 dec. 2011, om 09:37 heeft Paul Eggleton het volgende geschreven:


On Friday 23 December 2011 09:28:31 Koen Kooi wrote:

Op 22 dec. 2011, om 16:06 heeft Jim Abernathy het volgende geschreven:

I know the examples in the documentation of Yocto use meta-intel a
lot
to get the board specific BSPs like meta-crownbay or meta-n450.

Is there a meta-ti or similar that gets you the meta-beagleboard and
meta-pandaboard?  If not how do you clone and checkout the pandaboard
BPS?

http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/


It has a README in there on how to set it up, read it and follow it
precisely.


Just out of interest, why does meta-texasinstruments depend on
meta-angstrom?


It needs extra things in overrides and reuses tasks from there.


Sorry for the follow-up, but if I clone the meta-texasinstruments bsp
repository and checkout the pandaboard-rework branch,
how does that relate to the Yocto branch/bsp yocto/standard/pandaboard
on the Yocto site?


I'll jump into the middle of the thread, and answer a couple of specific
questions and leave the larger what depends on what, and where
things evolve and why .. for another day.

The yocto/standard/pandaboard in the 3.0 kernel tree is the refresh/update
of a reference BSP for the 3.0 (and newer) kernel(s).


Who is the intended audience of this BSP? The Angstrom/meta-to layer is
obviously intended for people using TI hardware and all the associated
peripherals. Without defining your audience better, this jsut adds to
the confusion end users are experiencing with all the words and layers
being used in emails. This is becoming a real problem as new users enter
the project.


Quite simply, the audience that needs a particular kernel version
and feature set, with the tooling to transition to a supported (i.e
not the yocto one) BSP.


You do realize that by doing this without informing anyone involved with the official 
pandaboard BSP the net effect is negative? And by 'negative' I mean "severe 
annoyance" among other things.


.. and why would you assume that precisely that hadn't been done ?
It has been, via management channels at multiple companies and
organizations and is exactly why I said "a layer you can't get"
and "work in progress".

So please, no need to jump to anything resembling 'annoyance'.
There's plenty of that to go around, and it isn't constructive.


I think it would be nice if we had a wiki document which listed
various BSPs for a given platform that are available using the
given layers and some words differentiating them. That can help
end users in understanding and deciding which to use.


AFAIK there are plans in this area for the 1.2 timeframe, perhaps
via the BSP portal that TomZ was creating. Something linked from the
wiki pages that list all the available layers would be the logical
place to locate something like this as well.

Richard may have more insight as to whether or not something is planned
like this.

Cheers,

Bruce
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto on Acer Aspire One NAV50

[Bruce Ashfield]

On 12-01-10 10:47 AM, James Abernathy wrote:

I created a core-image-sato using the meta-n450 BSP hoping I could work
with it on the Acer Aspire One 532h-2588. However, that netbook uses the
Atheros AR5B95 wireless NIC and the Atheros AR8132 wired NIC, which are
not recognized. Is there anything already in Yocto that could be turned
on to support these devices, or am I left with porting the drives?
Since Ubuntu 11.10 with it's kernel 3.0.0 supports these devices and
runs on the netbook, I'm guessing it's a matter of configuring the
kernel to include these modules.
Does this sound right??


That should be all that is required. If the drivers you need are
indeed in 3.0 (I didn't go check explicitly), then you can create
a bbappend for the BSP in a layer, and add a configuration fragment
that enables the drivers you need (as modules or builtin, your
choice).

Examples of config fragments are in the BSP/kernel guides found on
the yocto project pages.

Cheers,

Bruce


Jim A


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


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

Re: [yocto] yocto on Acer Aspire One NAV50

[Bruce Ashfield]

On 12-01-10 11:31 AM, Jim Abernathy wrote:

On 01/10/2012 10:50 AM, Bruce Ashfield wrote:

On 12-01-10 10:47 AM, James Abernathy wrote:

I created a core-image-sato using the meta-n450 BSP hoping I could work
with it on the Acer Aspire One 532h-2588. However, that netbook uses the
Atheros AR5B95 wireless NIC and the Atheros AR8132 wired NIC, which are
not recognized. Is there anything already in Yocto that could be turned
on to support these devices, or am I left with porting the drives?
Since Ubuntu 11.10 with it's kernel 3.0.0 supports these devices and
runs on the netbook, I'm guessing it's a matter of configuring the
kernel to include these modules.
Does this sound right??


That should be all that is required. If the drivers you need are
indeed in 3.0 (I didn't go check explicitly), then you can create
a bbappend for the BSP in a layer, and add a configuration fragment
that enables the drivers you need (as modules or builtin, your
choice).

Examples of config fragments are in the BSP/kernel guides found on
the yocto project pages.


If I'm only making changes to the .config parameters, do I still need to
create
a local bare clone of the yocto kernel and also git the poky-extras
repository as mentioned
in the Developers Manual appendix B?


Nope. You can just have your config fragment appended to the SRC_URI
and it will be applied to the existing BSP. Only if you were creating
a completely new board, and wanted to work with a local tree would you
need those clones.

Cheers,

Bruce



Jim A



Cheers,

Bruce


Jim A


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






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

Re: [yocto] [PATCH 0/2][KERNEL] new yocto/emgd-1.10 feature branch

[Bruce Ashfield]

On 12-01-02 02:31 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

This patchset adds a new yocto/emgd-1.10 feature branch to linux-yocto-3.0,
alongside the existing yocto/emgd branch containing emgd-1.8.

Bruce, please don't merge this yet though - it depends on the new emgd-1.10
recipe, which in turn depends on some new LICENSE_FLAGS functionality being
merged.  Will let you know when all that's taken care of and it's safe to
pull this in.


Just pinging. I assume these are safe to merge now ?

Bruce



Thanks,

Tom

The following changes since commit 6b4bf6173b0bd2d1619a8218bac66ebc4681dd35:
   Maurice Ma (1):
 x86, efi: Convert efi_phys_get_time() args to physical addresses

are available in the git repository at:

   git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git 
tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0
   
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0

Tom Zanussi (2):
   yocto/emgd: emgd 1.10 driver
   yocto/emgd: initial build fixups

  drivers/gpu/drm/Kconfig|9 +
  drivers/gpu/drm/Makefile   |1 +
  drivers/gpu/drm/emgd/Makefile  |  294 +
  drivers/gpu/drm/emgd/emgd/cfg/config.h |  113 +
  drivers/gpu/drm/emgd/emgd/cfg/config_default.h |  198 +
  drivers/gpu/drm/emgd/emgd/cfg/config_helper.c  |  244 +
  .../gpu/drm/emgd/emgd/core/init/cmn/igd_global.c   |   34 +
  drivers/gpu/drm/emgd/emgd/core/init/cmn/igd_init.c |  918 +++
  .../drm/emgd/emgd/core/init/cmn/init_dispatch.h|   65 +
  drivers/gpu/drm/emgd/emgd/core/init/plb/init_plb.c |  458 ++
  .../drm/emgd/emgd/core/init/plb/micro_init_plb.c   |  631 ++
  drivers/gpu/drm/emgd/emgd/core/init/tnc/init_tnc.c |  621 ++
  .../drm/emgd/emgd/core/init/tnc/micro_init_tnc.c   |  992 +++
  drivers/gpu/drm/emgd/emgd/display/dsp/cmn/dsp.c| 2368 +++
  .../drm/emgd/emgd/display/dsp/cmn/dsp_dispatch.h   |   64 +
  .../gpu/drm/emgd/emgd/display/dsp/plb/dsp_plb.c|  709 ++
  .../gpu/drm/emgd/emgd/display/dsp/tnc/dsp_tnc.c|  542 ++
  .../gpu/drm/emgd/emgd/display/mode/cmn/igd_mode.c  | 2219 +++
  drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.c | 1347 
  drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.h |   59 +
  .../drm/emgd/emgd/display/mode/cmn/micro_mode.c| 1744 +
  .../drm/emgd/emgd/display/mode/cmn/mode_dispatch.h |  383 ++
  .../gpu/drm/emgd/emgd/display/mode/cmn/vga_mode.c  | 1467 +
  .../drm/emgd/emgd/display/mode/plb/clocks_plb.c|  701 ++
  .../drm/emgd/emgd/display/mode/plb/kms_mode_plb.c  | 1102 
  .../emgd/emgd/display/mode/plb/micro_mode_plb.c| 1372 
  .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.c  | 1932 ++
  .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.h  |   47 +
  .../drm/emgd/emgd/display/mode/tnc/clocks_tnc.c| 1180 
  .../drm/emgd/emgd/display/mode/tnc/kms_mode_tnc.c  | 1721 +
  .../emgd/emgd/display/mode/tnc/micro_mode_tnc.c| 2643 
  .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.c  | 1997 ++
  .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.h  |   52 +
  drivers/gpu/drm/emgd/emgd/display/pd/cmn/pd.c  |  516 ++
  .../gpu/drm/emgd/emgd/display/pi/cmn/displayid.c   | 1058 +++
  drivers/gpu/drm/emgd/emgd/display/pi/cmn/edid.c| 1187 
  .../drm/emgd/emgd/display/pi/cmn/i2c_dispatch.h|   78 +
  drivers/gpu/drm/emgd/emgd/display/pi/cmn/igd_pi.c  |  260 +
  .../gpu/drm/emgd/emgd/display/pi/cmn/mode_table.c  | 2545 
  .../gpu/drm/emgd/emgd/display/pi/cmn/pd_init_all.c |  215 +
  drivers/gpu/drm/emgd/emgd/display/pi/cmn/pi.c  | 1883 ++
  drivers/gpu/drm/emgd/emgd/display/pi/plb/i2c_plb.c |  940 +++
  .../drm/emgd/emgd/display/pi/tnc/i2c_bitbash_tnc.c |  599 ++
  .../drm/emgd/emgd/display/pi/tnc/i2c_gmbus_tnc.c   |  929 +++
  drivers/gpu/drm/emgd/emgd/drm/drm_emgd_private.h   |  167 +
  drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c |  512 ++
  drivers/gpu/drm/emgd/emgd/drm/emgd_crtc.c  | 1004 +++
  drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c   | 2399 +++
  drivers/gpu/drm/emgd/emgd/drm/emgd_drv.h   |  199 +
  drivers/gpu/drm/emgd/emgd/drm/emgd_encoder.c   |  474 ++
  drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c| 1403 
  drivers/gpu/drm/emgd/emgd/drm/emgd_fbcon.c |  801 +++
  drivers/gpu/drm/emgd/emgd/drm/emgd_interface.c | 2583 
  drivers/gpu/drm/emgd/emgd/drm/emgd_mmap.c  |  186 +
  drivers/gpu/drm/emgd/emgd/drm/emgd_test_pvrsrv.c   | 1365 
  drivers/gpu/drm/emgd/emgd/drm/image_data.h |   33 +
  drivers/gpu/drm/emgd/emgd/drm/splash_screen.c  | 2221 +++
  drivers/gpu/drm/emgd/emgd/drm/splash_screen.h  |  280 +
  drivers/gpu/drm/emgd/emgd/drm/user_config.c|  252 +
  drivers/gpu/drm/emgd/emgd/drm/user_config.h|  113 +
  drivers/gpu/drm/emgd/emgd/gmm/gmm.c| 1005 +++
  drivers/gpu/drm/emgd/emgd/gmm/gtt.c 

Re: [yocto] [PATCH 0/2][KERNEL] new yocto/emgd-1.10 feature branch

[Bruce Ashfield]

On 12-01-10 03:55 PM, Tom Zanussi wrote:

On Tue, 2012-01-10 at 15:50 -0500, Bruce Ashfield wrote:

On 12-01-02 02:31 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

This patchset adds a new yocto/emgd-1.10 feature branch to linux-yocto-3.0,
alongside the existing yocto/emgd branch containing emgd-1.8.

Bruce, please don't merge this yet though - it depends on the new emgd-1.10
recipe, which in turn depends on some new LICENSE_FLAGS functionality being
merged.  Will let you know when all that's taken care of and it's safe to
pull this in.


Just pinging. I assume these are safe to merge now ?


No, LICENSE_FLAGS has hit another snag - until that's in we can't pull
in the emgd-1.10 recipe, and therefore can't pull the 1.10 kernel bits
in either...


ok. no worries at all. I was wondering if I missed the update.
No rush, I'll be able to merge this when it's ready.

Bruce



Tom



Bruce



Thanks,

Tom

The following changes since commit 6b4bf6173b0bd2d1619a8218bac66ebc4681dd35:
Maurice Ma (1):
  x86, efi: Convert efi_phys_get_time() args to physical addresses

are available in the git repository at:

git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git 
tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0

Tom Zanussi (2):
yocto/emgd: emgd 1.10 driver
yocto/emgd: initial build fixups

   drivers/gpu/drm/Kconfig|9 +
   drivers/gpu/drm/Makefile   |1 +
   drivers/gpu/drm/emgd/Makefile  |  294 +
   drivers/gpu/drm/emgd/emgd/cfg/config.h |  113 +
   drivers/gpu/drm/emgd/emgd/cfg/config_default.h |  198 +
   drivers/gpu/drm/emgd/emgd/cfg/config_helper.c  |  244 +
   .../gpu/drm/emgd/emgd/core/init/cmn/igd_global.c   |   34 +
   drivers/gpu/drm/emgd/emgd/core/init/cmn/igd_init.c |  918 +++
   .../drm/emgd/emgd/core/init/cmn/init_dispatch.h|   65 +
   drivers/gpu/drm/emgd/emgd/core/init/plb/init_plb.c |  458 ++
   .../drm/emgd/emgd/core/init/plb/micro_init_plb.c   |  631 ++
   drivers/gpu/drm/emgd/emgd/core/init/tnc/init_tnc.c |  621 ++
   .../drm/emgd/emgd/core/init/tnc/micro_init_tnc.c   |  992 +++
   drivers/gpu/drm/emgd/emgd/display/dsp/cmn/dsp.c| 2368 +++
   .../drm/emgd/emgd/display/dsp/cmn/dsp_dispatch.h   |   64 +
   .../gpu/drm/emgd/emgd/display/dsp/plb/dsp_plb.c|  709 ++
   .../gpu/drm/emgd/emgd/display/dsp/tnc/dsp_tnc.c|  542 ++
   .../gpu/drm/emgd/emgd/display/mode/cmn/igd_mode.c  | 2219 +++
   drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.c | 1347 
   drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.h |   59 +
   .../drm/emgd/emgd/display/mode/cmn/micro_mode.c| 1744 +
   .../drm/emgd/emgd/display/mode/cmn/mode_dispatch.h |  383 ++
   .../gpu/drm/emgd/emgd/display/mode/cmn/vga_mode.c  | 1467 +
   .../drm/emgd/emgd/display/mode/plb/clocks_plb.c|  701 ++
   .../drm/emgd/emgd/display/mode/plb/kms_mode_plb.c  | 1102 
   .../emgd/emgd/display/mode/plb/micro_mode_plb.c| 1372 
   .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.c  | 1932 ++
   .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.h  |   47 +
   .../drm/emgd/emgd/display/mode/tnc/clocks_tnc.c| 1180 
   .../drm/emgd/emgd/display/mode/tnc/kms_mode_tnc.c  | 1721 +
   .../emgd/emgd/display/mode/tnc/micro_mode_tnc.c| 2643 
   .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.c  | 1997 ++
   .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.h  |   52 +
   drivers/gpu/drm/emgd/emgd/display/pd/cmn/pd.c  |  516 ++
   .../gpu/drm/emgd/emgd/display/pi/cmn/displayid.c   | 1058 +++
   drivers/gpu/drm/emgd/emgd/display/pi/cmn/edid.c| 1187 
   .../drm/emgd/emgd/display/pi/cmn/i2c_dispatch.h|   78 +
   drivers/gpu/drm/emgd/emgd/display/pi/cmn/igd_pi.c  |  260 +
   .../gpu/drm/emgd/emgd/display/pi/cmn/mode_table.c  | 2545 
   .../gpu/drm/emgd/emgd/display/pi/cmn/pd_init_all.c |  215 +
   drivers/gpu/drm/emgd/emgd/display/pi/cmn/pi.c  | 1883 ++
   drivers/gpu/drm/emgd/emgd/display/pi/plb/i2c_plb.c |  940 +++
   .../drm/emgd/emgd/display/pi/tnc/i2c_bitbash_tnc.c |  599 ++
   .../drm/emgd/emgd/display/pi/tnc/i2c_gmbus_tnc.c   |  929 +++
   drivers/gpu/drm/emgd/emgd/drm/drm_emgd_private.h   |  167 +
   drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c |  512 ++
   drivers/gpu/drm/emgd/emgd/drm/emgd_crtc.c  | 1004 +++
   drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c   | 2399 +++
   drivers/gpu/drm/emgd/emgd/drm/emgd_drv.h   |  199 +
   drivers/gpu/drm/emgd/emgd/drm/emgd_encoder.c   |  474 ++
   drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c| 1403 
   drivers/gpu/drm/emgd/emgd/drm/emgd_fbcon.c |  801 +++
   drivers/gpu/drm/emgd/emgd/drm/emgd_interface.c | 2583 
   drivers/gpu/drm/emgd/emgd/drm/emgd_mmap.c   

Re: [yocto] Request to enable SMP and virtio for qemux86/x86-64

[Bruce Ashfield]

On 12-01-11 02:01 AM, Zhai, Edwin wrote:

Bruce,
Can we enable SMP and virtio by default for qemux86/x86-64? This can achieve
huge perf boost for workload inside qemu. E.g. we enabled self-hosted image,
where we build yocto inside qemu.

Attached patch showes the kernel config option.

Is it reasonable?


It should be. I just need to look at the fallback modes, and how this
impacts different host systems. That being said, I've run with similar
configs in the past (depending on the workload) with no issues.

qemux8-64 is already SMP, so it would just need the addition of virtio
devices, which just means we'd look at this as any BSP/target config
update.

But with graceful degradation (i.e maxcpus with SMP set) and agreement
that we'd like to simulate SMP by default, then we can make the change
and I'll merge it into the base config for the target and pull it into
the kernel tree.

Cheers,

Bruce






Thanks,
Edwin



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

Re: [yocto] Does Edison work with Beagleboard & linux-yocto-3.0 kernel?

[Bruce Ashfield]

On 12-01-11 09:41 AM, Brian Hutchinson wrote:

Hi,

I followed the example in the "Yocto Project Development Manual" for
setting up a local kernel repo and it didn't go so well.

A month or two ago I checked out Edison and was able to build all the
images required for Beagleboard and it booted fine (using command line
... not hob.  Tried hob but couldn't get it to work).

So then I checked out linux-yocto-3.0 kernel and setup a local kernel
git repo and went through the process of setting up poky-extras,
modifying bblayers.conf etc. to point to my local repo.

Any time I try to build core-image-minimal it looks like it always
wants to use the 2.6.37 recipe instead of finding my 3.0 repo.  I've
tried everything I can think of and I must me missing something.

So, I guess my questions are:

1.  Will linux-yocto-3.0 work with Beagleboard?


It will. I sent patches recently to make that the preferred version
in the master branch. Cherry picking that change would probably
be all you would need.


2.  Is the example for setting up for kernel modification in the
development manual still valid for Edison?


Should be.

Bruce



Regards,

Brian
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


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

Re: [yocto] Does Edison work with Beagleboard & linux-yocto-3.0 kernel?

[Bruce Ashfield]

On 12-01-11 10:20 AM, Brian Hutchinson wrote:

On Wed, Jan 11, 2012 at 9:57 AM, Bruce Ashfield
  wrote:

It will. I sent patches recently to make that the preferred version
in the master branch. Cherry picking that change would probably
be all you would need.



2.  Is the example for setting up for kernel modification in the
development manual still valid for Edison?



Should be.



Would I get that change if I just did a git pull or do I have to do
something else?  I did a git pull to update my Edison checkout last
night realizing that I hadn't done one in a while and then ran a new
clean build and still ran into the same problem.  After triple
checking my work I figured it was time to post.


Just so I'm clear. You are asking about the switch to 3.0 as the
default ? If so, that was only done in master for the upcoming 1.2
release and not on the edison branch, so you wouldn't pick it up
by pulling.

Cheers,

Bruce



Regards,

Brian


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

Re: [yocto] Does Edison work with Beagleboard & linux-yocto-3.0 kernel?

[Bruce Ashfield]

On 12-01-11 10:24 AM, Jack Mitchell wrote:

On 11/01/12 15:20, Brian Hutchinson wrote:

On Wed, Jan 11, 2012 at 9:57 AM, Bruce Ashfield
  wrote:

It will. I sent patches recently to make that the preferred version
in the master branch. Cherry picking that change would probably
be all you would need.



2.  Is the example for setting up for kernel modification in the
development manual still valid for Edison?


Should be.


Would I get that change if I just did a git pull or do I have to do
something else?  I did a git pull to update my Edison checkout last
night realizing that I hadn't done one in a while and then ran a new
clean build and still ran into the same problem.  After triple
checking my work I figured it was time to post.

Regards,

Brian
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


I can chime in here. I am currently trying to get my Beagleboard running
on the master branch, and it is pulling in kernel 3.0.12. However I
cannot get it to boot, I get as far as here:

*Texas Instruments X-Loader 1.5.0 (Jan 11 2012 - 14:06:12)
Beagle xM
Reading boot sector
Loading u-boot.bin from mmc


U-Boot 2011.06 (Jan 11 2012 - 14:15:11)

OMAP3630/3730-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
DRAM: 512 MiB
NAND: 0 MiB
MMC: OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment

In: serial
Out: serial
Err: serial
Beagle unknown 0x02
No EEPROM on expansion board
Die ID #0ed800229ff80163810c15007017
Hit any key to stop autoboot: 0
SD/MMC found on device 0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
reading uImage

3106580 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 8200 ...
Image Name: Linux-3.0.12-yocto-standard+
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3106516 Bytes = 3 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

*Where it hangs and won't go any further. I am watching it over serial
using a baud rate of 115200. It's a bit worrying that uBoot doesn't pick
up the Beagle revision... I'm sure it used to when I was doing testing a
few months ago.


Interesting. You can open a bug on this, boot and sanity/peripheral tests
were performed before I made the switch. So if this is broken, that's
a bug and we can look into it.

As you hinted, including the uboot build/information would be useful,
since perhaps that has gotten out of sync.

Cheers,

Bruce



Cheers,
Jack.



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


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

Re: [yocto] Does Edison work with Beagleboard & linux-yocto-3.0 kernel?

[Bruce Ashfield]

On 12-01-11 03:35 PM, Brian Hutchinson wrote:

  wrote:

Just so I'm clear. You are asking about the switch to 3.0 as the
default ? If so, that was only done in master for the upcoming 1.2
release and not on the edison branch, so you wouldn't pick it up
by pulling.


Thanks!  I did a git checkout -b master origin/master and will try again.


Thanks Bruce for pointing me in the right direction.  I just wanted to
follow up.

I switched to master branch and did a clean build for Beagleboard.  I
can confirm that it worked.  I blew my SD Card away and put freshly
built yocto images of MLO, u-boot.bin&  uImage and my Beagleboard xM
boots fine (one last question after this output below):

Texas Instruments X-Loader 1.5.0 (Jan 11 2012 - 12:41:55)
Beagle xM
Reading boot sector
Loading u-boot.bin from mmc


U-Boot 2011.06 (Jan 11 2012 - 12:41:50)

OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  512 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
In:serial
Out:   serial
Err:   serial
Beagle xM Rev A
No EEPROM on expansion board
Die ID #33501bf0015739ea07035019
Hit any key to stop autoboot:  0
SD/MMC found on device 0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
reading uImage

3106612 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 8200 ...
Image Name:   Linux-3.0.12-yocto-standard+
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:3106548 Bytes = 3 MiB
Load Address: 80008000
Entry Point:  80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Yocto (Built by Poky 6.0) 1.1+snapshot-20120111 beagleboard ttyO2

beagleboard login: root
root@beagleboard:~# ls
root@beagleboard:~# uptime
  19:06:08 up 0 min,  load average: 1.08, 0.30, 0.10
root@beagleboard:~# uname -a
Linux beagleboard 3.0.12-yocto-standard+ #1 PREEMPT Wed Jan 11
13:53:06 EST 2012 armv7l GNU/Linux
root@beagleboard:~#


Excellent!




... so now I'm back to trying to get poky to use my local
linux-yocto-3.0 git repo.

One more question.  When I setup linux-yocto_3.0.bbappend in
poky-extras/meta-kernel-dev/recipies-kernel/linux, do I use
"yocto/standard/beagleboard" for KMACHINE?


If you still want the default (which you likely do here), you
can leave KMACHINE untouched in your bbappend and the inherited
value from the core layers will take care of everything. Get that
working on your local clone, and then try tweaking things :)

Cheers,

Bruce



Thanks again,

Brian


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

Re: [yocto] Does Edison work with Beagleboard & linux-yocto-3.0 kernel?

[Bruce Ashfield]

On 12-01-12 10:21 AM, Brian Hutchinson wrote:

Yet another follow up.  I finally found my C3 Beagleboard and the
default kernel built off master yesterday works on that platform too.

I was able to do another build with the tips you guys gave and it
looks like it is picking up the kernel from my local git repo now.  I
did the "calibrate" example and while I couldn't see the printk's due
to the silent boot being turned on somehow, uname -a was different
than the default image  mine is now:

root@beagleboard:~# uname -a
Linux beagleboard 3.0.14-yocto-standard+ #1 PREEMPT Thu Jan 12
08:45:10 EST 2012 armv7l GNU/Linux

And just for sanity, I made another copy of my bare clone and verified
that I pushed the "calibrate" changes correctly.

So it looks like I'm good now thanks to your help!

Do I have to do a cleanall every time I'm finished pushing changes
back to my local kernel repo?


The bitbake AUTOREV code should take care of updating the clone
of your local repo in downloads/git2. I take it that this isn't
happening ?



Is there a document that gives clues as to how to setup a local u-boot
repo for making changes to it?  Is is simply changing the u-boot
recipe SRC_URI to use my local u-boot git repo in
poky/meda/recipes-bsp/u-boot or is it more involved than that?  Is
there a u-boot dev layer like the poky-extras/meta-kernel-dev?


It should be (largely) as simple as that. We could create something
simple and throw it in with the meta-kernel-dev layer if there's any
interest in adding it.

Cheers,

Bruce



Regards,

Brian


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

Re: [yocto] Does Edison work with Beagleboard & linux-yocto-3.0 kernel?

[Bruce Ashfield]

On 12-01-12 11:20 AM, Brian Hutchinson wrote:

On Thu, Jan 12, 2012 at 11:00 AM, Bruce Ashfield
  wrote:

The bitbake AUTOREV code should take care of updating the clone
of your local repo in downloads/git2. I take it that this isn't
happening ?


... haven't tried ... was just sticking to the example in the
documentation which says to push changes and do a cleanall.  The spin


Good point. I hadn't noticed that it was in there. Worth trying
without it, and raising a bug if it isn't required. It's
bitbake internals rather than kernel at play here, so I'm far
from authoritative about what should or shouldn't work.


time on my dev machine wasn't too bad but long enough to get old quick
if I had to do it often.


Agreed!




It should be (largely) as simple as that. We could create something
simple and throw it in with the meta-kernel-dev layer if there's any
interest in adding it.


Just wanting to know what the "best practice" is as I have lots of
platforms to support.


I prefer to work this way, since managing patches in a source git
repository is much easier for me. If you only have a few patches,
then they can just be pushed on top and added to the SRC_URI, but
you'd be doing more development under tmp/work/ in that case .. and
I'm paranoid about losing things :)

Cheers,

Bruce



Regards,

Brian


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

Re: [yocto] Does Edison work with Beagleboard & linux-yocto-3.0 kernel?

[Bruce Ashfield]

On 12-01-12 11:48 AM, Brian Hutchinson wrote:

On Thu, Jan 12, 2012 at 11:24 AM, Bruce Ashfield
  wrote:

I prefer to work this way, since managing patches in a source git
repository is much easier for me. If you only have a few patches,
then they can just be pushed on top and added to the SRC_URI, but
you'd be doing more development under tmp/work/ in that case .. and
I'm paranoid about losing things :)


I know it probably isn't the best way (did it mostly because I was in
a hurry and never took the time to think about the "right" way to do
it) but I've made changes to the kernel&  u-boot before in the tmp
directories (with Angstrom and Arago) and build images manually (make
uImage etc.) and that was OK for quick/dirty things but I've gotten
burned before by forgetting my changes and doing a bitbake build and
wiping out my changes.   I like the method of pointing yocto to local
git repos and think that is better for long term development as it
will contain history and would be easy to determine what changed etc.
I'd like to do something similar with u-boot and thought you guys had
worked out a defacto standard way but in looking through all the docs
it doesn't look that way.


Ah yes. Nothing in particular. I was a non-oe import to yocto, so a
lot of what I've done is from being bitten in the past and making sure
that it didn't happen to me in a new environment.

Of course, I'm all for general solutions and getting feedback as well!

Cheers,

Bruce



Regards,

Brian


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

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bruce Ashfield]

On 12-01-12 03:52 PM, Darren Hart wrote:

On 01/12/2012 12:39 PM, Tom Zanussi wrote:

On Fri, 2011-12-16 at 19:03 -0800, Bruce Ashfield wrote:

On 11-12-16 8:34 PM, Darren Hart wrote:

On 12/16/2011 05:22 PM, Bodke, Kishore K wrote:


With the attached Darren's kern-tools-native_git.bb file, build was success.
Thanks
Kishore.


See the patch I just sent:kern-tools: Include do_install() in bbappend
for what I believe to be the solution.

I suppose the proper solution would be to version the kern-tools-native
recipe when major things like that change, but given the nature of this
layer, I think the above patch is adequate.


That's not the solution to either problem (well, yes, it's a solution
and there's nothing inherently wrong with it, it's just covering up
the underlying issue) which is a layer dependency issue. In this case,
meta-kernel-dev tracks the master branch of poky, not any other branch
or version. And that is implicit, not explicit, hence why it got into
this tangle.

We could simply branch meta-kernel-dev and have an edison branch for
it, not modify the appends to contain something that will just break
again in the future.

But meta-kernel-dev isn't officially used by much at the moment, so
I'm not convinced that branching it is worth the trouble (but I can
be convinced otherwise). I'd rather either just remove the kern-tools
bbappend (I'm probably the only one on the planet that really needs
it), or just trust people to know what they are up to with the
meta-kernel-dev layer.



Revisiting this - meta-kernel-dev is used in the documentation, and
Scott has now run up against this when testing and updating it.  Since
the documentation does use edison, and the walk-throughs have the user
check out edison branches of both poky and the BSP layers, it would be
consistent to have the user also do the same for meta-kernel-dev.
Probably just an edison branch with the kern-tools bbappend removed
would work fine...

Tom


Works for me.


Seems ok. I can create a branch shortly, once I'm slightly out from
under my 3.2 tree creation rush.

Bruce





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

Re: [yocto] Developer Manual Appendix B example

[Bruce Ashfield]

On 12-01-12 09:50 PM, James Abernathy wrote:
I'm trying to do the Developer Manual Appendix B example exactly as 
written only changing the path to my home directory. When I get to 
B.1.8.3, bitbake after patching the kernel calibrate.c and modifiing 
the path to the local git repository for linux-yocto, I get an error 
on the build.  The log file of the error is below:


Funny how things tend to arrive in bunches. We just discussed this today 
on the
list. The meta-kernel-dev layer is tied to master, and causes this 
problem when
used with edison. And that's what you are seeing here. I'm going to 
create a edison

branch for meta-kernel-dev to match up the tool SRCREVs.

In the meantime, if you remove the kern-tools-native_git.bbappend from 
the meta-kernel-dev
layer, the AUTOREV setting will be removed, and you won't pull in tools 
that are too

new for the matching kernel.

Cheers,

Bruce



[INFO] doing kernel configme
[INFO] Branch yocto/standard/common-pc/base used by common-pc-standard.scc
[INFO] collecting configs in ./meta/meta-series
mv: cannot stat 
`/home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/linux-qemux86-standard-build/.tmp.config*': 
No such file or directory

creation of pre-processed config data failed
config of yocto/standard/common-pc/base (common-pc-standard.scc) failed
ERROR: Function 'do_kernel_configme' failed (see 
/home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/temp/log.do_kernel_configme.15214 
for further information)


Any help would be appreciated.

Jim A


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


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

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

[Bruce Ashfield]

On 12-01-12 03:39 PM, Tom Zanussi wrote:

On Fri, 2011-12-16 at 19:03 -0800, Bruce Ashfield wrote:

On 11-12-16 8:34 PM, Darren Hart wrote:

On 12/16/2011 05:22 PM, Bodke, Kishore K wrote:


With the attached Darren's kern-tools-native_git.bb file, build was success.
Thanks
Kishore.


See the patch I just sent:kern-tools: Include do_install() in bbappend
for what I believe to be the solution.

I suppose the proper solution would be to version the kern-tools-native
recipe when major things like that change, but given the nature of this
layer, I think the above patch is adequate.


That's not the solution to either problem (well, yes, it's a solution
and there's nothing inherently wrong with it, it's just covering up
the underlying issue) which is a layer dependency issue. In this case,
meta-kernel-dev tracks the master branch of poky, not any other branch
or version. And that is implicit, not explicit, hence why it got into
this tangle.

We could simply branch meta-kernel-dev and have an edison branch for
it, not modify the appends to contain something that will just break
again in the future.

But meta-kernel-dev isn't officially used by much at the moment, so
I'm not convinced that branching it is worth the trouble (but I can
be convinced otherwise). I'd rather either just remove the kern-tools
bbappend (I'm probably the only one on the planet that really needs
it), or just trust people to know what they are up to with the
meta-kernel-dev layer.



Revisiting this - meta-kernel-dev is used in the documentation, and
Scott has now run up against this when testing and updating it.  Since
the documentation does use edison, and the walk-throughs have the user
check out edison branches of both poky and the BSP layers, it would be
consistent to have the user also do the same for meta-kernel-dev.
Probably just an edison branch with the kern-tools bbappend removed
would work fine...


I opted to simply repeat the SRCREV from the main kern-tools
repository in the meta-kernel-dev bbappend. This gave me a chance
to add a bit of warning around changing the SRCREV when working
on a non-master branch.

It should be present in an new edison branch of the extras
repo. So anyone seeing this problem, can do a pull and take it
for a spin.

Let me know if this doesn't work for some reason.

Cheers,

Bruce



Tom


Alternatively, we wait for layer dependency tooling and use that :)

Cheers,

Bruce



--
Darren



-Original Message-
From: Bodke, Kishore K
Sent: Friday, December 16, 2011 5:07 PM
To: Hart, Darren
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: RE: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

Hi,
I still get the same error below after changing the kern-tools-native_git.bb 
file.

SRCREV ?= "364437739c45a5e771d1f7b3ac73c35f1328fd97"
PR = r11


ERROR: Function 'do_kernel_configme' failed (see 
/usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.27942
 for further information)
ERROR: Logfile of failure stored in: 
/usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.27942
Log data follows:
| [INFO] doing kernel configme
| [INFO] Branch yocto/standard/preempt-rt/base used by common-pc-preempt-rt.scc
| [INFO] collecting configs in ./meta/meta-series
| mv: cannot stat 
`/usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
 No such file or directory
| creation of pre-processed config data failed
| config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) failed
| ERROR: Function 'do_kernel_configme' failed (see 
/usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.27942
 for further information)
NOTE: package 
linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
 task do_kernel_configme: Failed
NOTE: package gcc-cross-4.6.1+svnr175454-r10: task do_configure: Started
ERROR: Task 716 
(/usr/local/src/yocto_1_1/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb, 
do_kernel_configme) failed with exit code '1'

Thanks
Kishore.

-Original Message-
From: Hart, Darren
Sent: Friday, December 16, 2011 3:08 PM
To: Bodke, Kishore K
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
branch.

On 12/16/201

Re: [yocto] Linux RT build fail

[Bruce Ashfield]

On 12-01-16 01:40 PM, Bodke, Kishore K wrote:

Hi,

I get build failure for the rt.

ERROR: Function 'do_patch' failed (see
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/temp/log.do_patch.32459
for further information)

ERROR: Logfile of failure stored in:
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/temp/log.do_patch.32459

Log data follows:

| ERROR: Function 'do_patch' failed (see
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/temp/log.do_patch.32459
for further information)

| Deleted branch meta-temp (was 620917d).

|

| ERROR: patch
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/linux/meta/cfg/kernel-cache/features/rt/rt-apply-patch-3.0.10-rt27.patch.patch
is not available


This is the problem. But I could have sworn that I fixed this, and
send a merge request. When I just checked now, it still looks broken.

That being said, we should have seen this before now. Are any -rt
kernels being build regularly on master ?

It is partially due to meta-kernel-dev picking up new kernel tools that
do strict checking on patches by default (hence my question about
anyone else building this on master).

I'm pushing a fix out now to the meta branch and will send it along
with my next consolidated pull request.

Cheers,

Bruce



|

| ERROR. Could not find an excutable target for
yocto/standard/preempt-rt/base

| ERROR. Could not locate meta series for preempt-rt-standard

| ERROR. Could not modify yocto/standard/preempt-rt/base

NOTE: package
linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1:
task do_patch: Failed

NOTE: package bzip2-1.0.6-r4: task do_compile: Succeeded

ERROR: Task 3
(/usr/local/src/jan13/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
do_patch) failed with exit code '1'

Is this anything to do with meta-kernel-dev I am using or something else?

Thanks

Kishore.



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

Re: [yocto] Request to enable SMP and virtio for qemux86/x86-64

[Bruce Ashfield]

On 12-01-12 08:14 AM, Zhai, Edwin wrote:

Bruce,
Thanks for your efforts!


FYI: I haven't forgotten about this, I'm just reworking a few
things with the 3.2 kernel tree, and will include this as part
of that effort. It will all be available soon.

Bruce



Edwin

On 2012/1/11 20:43, Bruce Ashfield wrote:

On 12-01-11 02:01 AM, Zhai, Edwin wrote:

Bruce,
Can we enable SMP and virtio by default for qemux86/x86-64? This can
achieve
huge perf boost for workload inside qemu. E.g. we enabled self-hosted
image,
where we build yocto inside qemu.

Attached patch showes the kernel config option.

Is it reasonable?


It should be. I just need to look at the fallback modes, and how this
impacts different host systems. That being said, I've run with similar
configs in the past (depending on the workload) with no issues.

qemux8-64 is already SMP, so it would just need the addition of virtio
devices, which just means we'd look at this as any BSP/target config
update.

But with graceful degradation (i.e maxcpus with SMP set) and agreement
that we'd like to simulate SMP by default, then we can make the change
and I'll merge it into the base config for the target and pull it into
the kernel tree.

Cheers,

Bruce






Thanks,
Edwin







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

Re: [yocto] Does Edison work with Beagleboard & linux-yocto-3.0 kernel?

[Bruce Ashfield]

On 12-01-22 10:33 PM, Brian Hutchinson wrote:

OK, hate to bring this up again but I must be doing something wrong.
My kernel changes don't appear to be getting picked up.  I thought it
was OK before but then I did some real work on the kernel and that is
when I realized something isn't right.

To recap from the previous emails, I'm following the Appendix B
example and trying to modify the kernel using a local git repo.

In going over the steps again, it looks like I didn't checkout a local
branch in the copy of the bare clone so I don't know if that is my
problem or not.  When I make a copy of the bare clone I see my changes
so my changes must be in the local git.  Here is what I did:

. I checked out master.
. I cd into poky and ran git clone
git://git.yoctoproject.org/poky-extras poky-extras
. Outside of poky I created a bare clone git clone linux-yocto-3.0.git
linux-yocto-3.0
. Inside linux-yocto-3.0 I think I checked out master.  I can't
remember.  When I do git branch in the copy of the bare clone it says
I'm on master
. When I sourced to build, I followed the example on one of the videos
and did "source poky/oe-init-build-env bb-test" so my conf dir is in
bb-test directory.  Here is what conf bblayers.conf has

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"

BBFILES ?= ""
BBLAYERS ?= " \
   /home/hutch/yocto/master/poky/meta \
   /home/hutch/yocto/master/poky/meta-yocto \
   /home/hutch/yocto/master/poky/poky-extras/meta-kernel-dev \
   "

. At this point, my copy of the bare clone is in /home/hutch/linux-yocto-3.0
. So, my linux-yocto_3.0.bbappend file looks like this:

FILESEXTRAPATHS := "${THISDIR}/${PN}"

COMPATIBLE_MACHINE = ${MACHINE}

# KMACHINE is the branch to build
# KMACHINE_  ?= "yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"

# KERNEL_FEATURES are features to be added to the kernel, and must
# point to configurations stored on the 'meta' branch of the kernel
# that is being built.
# KERNEL_FEATURES ?=

# It is often nice to have a local clone of the kernel repos, to
# allow patches to be staged, branches created, etc. Modify

# KSRC_linux_yocto to point to your local clone as appropriate.
KSRC_linux_yocto ?= /home/hutch/linux-yocto-3.0.git
KMACHINE ?= "yocto/${LINUX_KERNEL_TYPE}/${KMACHINE}"

SRC_URI = 
"git://${KSRC_linux_yocto};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

KERNEL_REVISION_CHECKING=
SRCREV=${AUTOREV}
#BB_LOCALCOUNT_OVERRIDE = "1"
LOCALCOUNT = "0"

. I'm working with spidev and user space gpio so I needed to turn
these things on in menuconfig so I ran:

bitbake linux-yocto -c menuconfig and then made my changes.

. Then I build the kernel with:

bitbake linux-yocto -c compile -f
bitbake linux-yocto

My first clue that my changes were not getting picked up is I didn't
have a /dev/spidev entry.  I found the board-omap3beagle.c file in tmp
and it didn't have my changes.

If I make another copy of my bare clone with git clone
linux-yocto-3.0.git linux-yocto-3.0_test2 ... I see my changes.

After I made my source changes I did:

git add arch/arm/mach-omap2/board-omap3beagle.c
git commit --signoff
git status (nothing else checked out)
git push origin master:master

On the target, if I zcat config.gz, I see the changes I made to
menuconfig but my source changes don't show up when I poke around in
tmp.

Not sure what went wrong but it doesn't appear to be picking up my
kernel changes when I bitbake and I don't understand why.  Hopefully I
provided enough info for someone to spot what I hosed up.


The beagle board would be building on the branch listed in the
meta-yocto layer.

KMACHINE_beagleboard = "yocto/standard/beagleboard"

Everything that you've done is fine, but pushing your changes to
master will ensure that they aren't checked out and built.

Cheers,

Bruce



Regards,

Brian
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


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

Re: [yocto] [PATCH][linux-yocto] pch_gbe: Do not abort probe on bad MAC

[Bruce Ashfield]

On 12-01-19 4:34 PM, Darren Hart wrote:

Bruce, please apply to linux-yocto-3.0/yocto/standard/base


Queued.

Bruce



Upstream-Status: Accepted (Linux 3.3)

If the MAC is invalid or not implemented, do not abort the probe. Issue
a warning and prevent bringing the interface up until a MAC is set manually
(via ifconfig $IFACE hw ether $MAC).

Tested on two platforms, one with a valid MAC, the other without a MAC. The real
MAC is used if present, the interface fails to come up until the MAC is set on
the other. They successfully get an IP over DHCP and pass a simple ping and
login over ssh test.

This is meant to allow the Inforce SYS940X development board:
http://www.inforcecomputing.com/SYS940X_ECX.html
(and others suffering from a missing MAC) to work with the mainline kernel.
Without this patch, the probe will fail and the interface will not be created,
preventing the user from configuring the MAC manually.

This does not make any attempt to address a missing or invalid MAC for the
pch_phub driver.

Signed-off-by: Darren Hart
CC: Arjan van de Ven
CC: Alan Cox
CC: Tomoya MORINAGA
CC: Jeff Kirsher
CC: "David S. Miller"
CC: Paul Gortmaker
CC: Jon Mason
CC: net...@vger.kernel.org
CC: Mark Brown
CC: David Laight
CC: Joe Perches
---
  drivers/net/pch_gbe/pch_gbe_main.c |   17 ++---
  1 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/net/pch_gbe/pch_gbe_main.c 
b/drivers/net/pch_gbe/pch_gbe_main.c
index eac3c5c..e7412f2 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -1701,6 +1701,12 @@ int pch_gbe_up(struct pch_gbe_adapter *adapter)
struct pch_gbe_rx_ring *rx_ring = adapter->rx_ring;
int err;

+   /* Ensure we have a valid MAC */
+   if (!is_valid_ether_addr(adapter->hw.mac.addr)) {
+   pr_err("Error: Invalid MAC address\n");
+   return -EINVAL;
+   }
+
/* hardware has been reset, we need to reload some things */
pch_gbe_set_multi(netdev);

@@ -2392,9 +2398,14 @@ static int pch_gbe_probe(struct pci_dev *pdev,

memcpy(netdev->dev_addr, adapter->hw.mac.addr, netdev->addr_len);
if (!is_valid_ether_addr(netdev->dev_addr)) {
-   dev_err(&pdev->dev, "Invalid MAC Address\n");
-   ret = -EIO;
-   goto err_free_adapter;
+   /*
+* If the MAC is invalid (or just missing), display a warning
+* but do not abort setting up the device. pch_gbe_up will
+* prevent the interface from being brought up until a valid MAC
+* is set.
+*/
+   dev_err(&pdev->dev, "Invalid MAC address, "
+   "interface disabled.\n");
}
setup_timer(&adapter->watchdog_timer, pch_gbe_watchdog,
(unsigned long)adapter);


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

Re: [yocto] tar ball vs. git development questions

[Bruce Ashfield]

On 12-01-23 08:10 AM, Gary Thomas wrote:

On 2012-01-23 05:51, jfabernathy wrote:

On 01/22/2012 08:12 PM, Gary Thomas wrote:

On 2012-01-22 13:19, James Abernathy wrote:

I have used both git and the tarball methods of bitbaking projects,
all of them derivatives of the examples in the Yocto documentation.
I was having issues using the local clone of
the Yocto kernel git repository this weekend. I had successfully
done that before, but I was rebuilding the PC workstation, and
getting everything setup and tested some of the
meta-intel BSPs to make sure I had everything right. Cloning the
linux-yocto-3.0 repository was successful, but the bakes against it
failed. I made sure I had poky-extras setup
right, but I still had problems. To isolate the problem, I changed
to building with the tarballs and everything worked fine.

So that got me thinking what are the differences between the 2 methods:

* I assume that if I use the tarball method, bitbake, using the
recipes, pulls down files from the online repositories and puts
those files into the centralized local download
directory ($DL_DIR), allowing reuse instead of re-downloading each
time. The content downloaded for linux-yocto-3.0 is exactly what
would be pulled from the local repository if
I used a local clone of the git repository for linux-yocto-3.0.
* If my assumption above is correct, if I'm not modifying the source
code of the kernel (only changing config parameters), then once
you've run at least one build with the
tarball method, the $DL_DIR directory contains all the files you'll
need to build any image with linux-yocto-3.0. So there is no need to
have a local clone of the kernel
repository for speeding up development. Am I right?
* If I have a successful creation of a bare clone of
linux-yocto-3.0.git, how could builds of Edison packages be failing?
That makes me concerned about using git and successfully
repeating builds of stable branches like Edison.


If you set BB_GENERATE_MIRROR_TARBALLS = "1" (e.g. in local.conf)
then you'll get tarballs which hold the git repositories after
download. You can then reuse these (by sharing the DL_DIR or
using a local mirror). Does that help with the issue you're seeing?


I'm not sure it does. I don't want poky to do more work. I have my
download directory, $DL_DIR, outside my build directory so I can keep
it run to run, as mentioned in the comments
in local.conf. I was trying to understand 2 basic questions:

1. what could be causing build failures using a freshly created bare
clone yesterday vs. using the poky-edison-6.0 tarball. It would be
scary if you could clone the linux-yocto-3.0
successfully one day and have it be used in a build successfully, but
clone it another day and it not work. I figured that bitbake/poky
pulled the same information into DL_DIR
regardless of whether you pulled from the bare clone locally or
straight from the on-line repository.


What kind of errors? Some details might help understand what the problem
is.


2. I was trying to look at items to speed up build runs. I thought
that if the downloads in DL_DIR were reused if they existed, it would
speed up a run. It seems to. So the
question is, after the first build, the files I need for
linux-yocto-3.0 are in DL_DIR regardless of whether they came from the
online repository or the local bare clone. right?


I think so, but I'm not 100% sure.


From my experience, this is true. Regardless of the SRCI_URI, the
downloads directory contains everything that poky/bitbake need to
do builds after the initial fetch has been performed. And that's
where subsequent updates are pullled.

Cheers,

Bruce



The way I have my system set up, I never download anything more
than once :-) I have a shared source repository which I point to
using MIRRORS and then all my builds are relative to that. If there
is new code, it gets downloaded and saved (as a tarball) in my sources
repository to be used by subsequent builds. To do this, I just have
these lines in .conf
# Provide pre-staged sources
SOURCE_MIRROR_URL ?= "file://${COREBASE}/sources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "1"
I don't define DL_DIR in local.conf so files only come from my mirror.

This process is so successful that I almost always run with
BB_NO_NETWORK="1"
which causes the fetcher to die if it can't find the file locally. If I
find
that I do need to download something new, I disable this and let the
fetcher
download it. I'll then have a saved tarball (either downloaded directly or
synthesized) in /downloads that I can push to my mirror.



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

Re: [yocto] Linux RT build fail

[Bruce Ashfield]

On 12-01-23 12:51 PM, Bodke, Kishore K wrote:

Hi Bruce,

Could you please let me know if the fix is available for this?


The 3.0 pull request was held up behind 3.2 work. But I just pushed
out a meta branch update that contained:

commit f1ef128bff854ce2614e655283ecca92d22f0b88
Author: Bruce Ashfield 
Date:   Mon Jan 16 13:45:11 2012 -0500

meta/rt: fix reference to non-existent patch

Signed-off-by: Bruce Ashfield 

:100644 100644 8c4d748... 4b9e9ed... M 
meta/cfg/kernel-cache/features/rt/rt.scc


Which is the error you are seeing. The change is destined
for master. If you are on another branch, it needs to be cherry
picked into your local meta branch.

Cheers,

Bruce



Thanks
Kishore.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Monday, January 16, 2012 10:44 AM
To: Bodke, Kishore K
Cc: yocto@yoctoproject.org; Hart, Darren
Subject: Re: Linux RT build fail

On 12-01-16 01:40 PM, Bodke, Kishore K wrote:

Hi,

I get build failure for the rt.

ERROR: Function 'do_patch' failed (see
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/temp/log.do_patch.32459
for further information)

ERROR: Logfile of failure stored in:
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/temp/log.do_patch.32459

Log data follows:

| ERROR: Function 'do_patch' failed (see
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/temp/log.do_patch.32459
for further information)

| Deleted branch meta-temp (was 620917d).

|

| ERROR: patch
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/linux/meta/cfg/kernel-cache/features/rt/rt-apply-patch-3.0.10-rt27.patch.patch
is not available


This is the problem. But I could have sworn that I fixed this, and
send a merge request. When I just checked now, it still looks broken.

That being said, we should have seen this before now. Are any -rt
kernels being build regularly on master ?

It is partially due to meta-kernel-dev picking up new kernel tools that
do strict checking on patches by default (hence my question about
anyone else building this on master).

I'm pushing a fix out now to the meta branch and will send it along
with my next consolidated pull request.

Cheers,

Bruce



|

| ERROR. Could not find an excutable target for
yocto/standard/preempt-rt/base

| ERROR. Could not locate meta series for preempt-rt-standard

| ERROR. Could not modify yocto/standard/preempt-rt/base

NOTE: package
linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1:
task do_patch: Failed

NOTE: package bzip2-1.0.6-r4: task do_compile: Succeeded

ERROR: Task 3
(/usr/local/src/jan13/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
do_patch) failed with exit code '1'

Is this anything to do with meta-kernel-dev I am using or something else?

Thanks

Kishore.





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

Re: [yocto] Linux RT build fail

[Bruce Ashfield]

On 12-01-23 8:17 PM, Bodke, Kishore K wrote:

I am building from master branch.

Below is the error I see.

ERROR: Function failed: do_patch (see 
/usr/local/src/juan/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+73dafd44ea875df654129b32b2877f342d5573e4_1+f1cc220f4ddf434bf254707c83a45794a63f117f-r1/temp/log.do_patch.25589
 for further information)
ERROR: Logfile of failure stored in: 
/usr/local/src/juan/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+73dafd44ea875df654129b32b2877f342d5573e4_1+f1cc220f4ddf434bf254707c83a45794a63f117f-r1/temp/log.do_patch.25589
Log data follows:
| ERROR: Function failed: do_patch (see 
/usr/local/src/juan/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+73dafd44ea875df654129b32b2877f342d5573e4_1+f1cc220f4ddf434bf254707c83a45794a63f117f-r1/temp/log.do_patch.25589
 for further information)
| checkpoint is already restored, nothing to do
|
| ERROR: patch 
/usr/local/src/juan/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+73dafd44ea875df654129b32b2877f342d5573e4_1+f1cc220f4ddf434bf254707c83a45794a63f117f-r1/linux/meta/cfg/kernel-cache/features/rt/rt-apply-patch-3.0.10-rt27.patch.patch
 is not available
|
| ERROR. Could not find an excutable target for yocto/standard/preempt-rt/base
| ERROR. Could not locate meta series for preempt-rt-standard
| ERROR. Could not modify yocto/standard/
NOTE: package 
linux-yocto-rt-3.0.14+git1+73dafd44ea875df654129b32b2877f342d5573e4_1+f1cc220f4ddf434bf254707c83a45794a63f117f-r1:
 task do_patch: Failed
ERROR: Task 714 
(/usr/local/src/juan/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb, 
do_patch) failed with exit code '1'


This is definitely fixed in the meta update I sent today, the "patch.patch"
is completely removed. So you'll have to wait for my request to be
merged, or cherry pick the change.

Bruce



Thanks
Kishore.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Monday, January 23, 2012 10:06 AM
To: Bodke, Kishore K
Cc: yocto@yoctoproject.org; Hart, Darren
Subject: Re: Linux RT build fail

On 12-01-23 12:51 PM, Bodke, Kishore K wrote:

Hi Bruce,

Could you please let me know if the fix is available for this?


The 3.0 pull request was held up behind 3.2 work. But I just pushed
out a meta branch update that contained:

commit f1ef128bff854ce2614e655283ecca92d22f0b88
Author: Bruce Ashfield
Date:   Mon Jan 16 13:45:11 2012 -0500

  meta/rt: fix reference to non-existent patch

  Signed-off-by: Bruce Ashfield

:100644 100644 8c4d748... 4b9e9ed... M
meta/cfg/kernel-cache/features/rt/rt.scc

Which is the error you are seeing. The change is destined
for master. If you are on another branch, it needs to be cherry
picked into your local meta branch.

Cheers,

Bruce



Thanks
Kishore.

-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Monday, January 16, 2012 10:44 AM
To: Bodke, Kishore K
Cc: yocto@yoctoproject.org; Hart, Darren
Subject: Re: Linux RT build fail

On 12-01-16 01:40 PM, Bodke, Kishore K wrote:

Hi,

I get build failure for the rt.

ERROR: Function 'do_patch' failed (see
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/temp/log.do_patch.32459
for further information)

ERROR: Logfile of failure stored in:
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/temp/log.do_patch.32459

Log data follows:

| ERROR: Function 'do_patch' failed (see
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/temp/log.do_patch.32459
for further information)

| Deleted branch meta-temp (was 620917d).

|

| ERROR: patch
/usr/local/src/jan13/poky/build-rt/tmp/work/cedartrail-poky-linux/linux-yocto-rt-3.0.14+git1+6ae3d992cf546184010e87a0349810198f1d167c_1+bcf4107c7f22d10952618a2ad146e6149d240cd2-r1/linux/meta/cfg/kernel-cache/features/rt/rt-apply-patch-3.0.10-rt27.patch.patch
is not available


This is the problem. But I could have sworn that I fixed this, and
send a merge request. When I just checked now, it still looks broken.

That being said, we should have seen this before now. Are any -rt
kernels being build regularly on master ?

It is partially due to meta-kernel-dev picking up new kernel tools that
do strict checking on patches by default (hence my question about
anyone else building this on master).

I'm pushing a fix out now to the meta branch and will send it along
with my next consolidated pull request.

Cheers,

Bruce



|

| ERROR. Could not find an excutable target for
yocto/standard/preempt-rt/base

| ERROR. Co

Re: [yocto] [PATCH][linux-yocto] pch_gbe: Do not abort probe on bad MAC

[Bruce Ashfield]

On 12-01-23 7:26 PM, Darren Hart wrote:



On 01/22/2012 08:01 PM, Bruce Ashfield wrote:

On 12-01-19 4:34 PM, Darren Hart wrote:

Bruce, please apply to linux-yocto-3.0/yocto/standard/base


Queued.


I don't see this in the repository yet, is it still pending? I'm trying
to write a BSP that is dependent on it.'


It's queued with the rest of my 3.0 updates. I've been spending
time on 3.2 and haven't pushed these out yet.

Bruce



Thanks,

Darren



Bruce



Upstream-Status: Accepted (Linux 3.3)

If the MAC is invalid or not implemented, do not abort the probe. Issue
a warning and prevent bringing the interface up until a MAC is set manually
(via ifconfig $IFACE hw ether $MAC).

Tested on two platforms, one with a valid MAC, the other without a MAC. The real
MAC is used if present, the interface fails to come up until the MAC is set on
the other. They successfully get an IP over DHCP and pass a simple ping and
login over ssh test.

This is meant to allow the Inforce SYS940X development board:
http://www.inforcecomputing.com/SYS940X_ECX.html
(and others suffering from a missing MAC) to work with the mainline kernel.
Without this patch, the probe will fail and the interface will not be created,
preventing the user from configuring the MAC manually.

This does not make any attempt to address a missing or invalid MAC for the
pch_phub driver.

Signed-off-by: Darren Hart
CC: Arjan van de Ven
CC: Alan Cox
CC: Tomoya MORINAGA
CC: Jeff Kirsher
CC: "David S. Miller"
CC: Paul Gortmaker
CC: Jon Mason
CC: net...@vger.kernel.org
CC: Mark Brown
CC: David Laight
CC: Joe Perches
---
   drivers/net/pch_gbe/pch_gbe_main.c |   17 ++---
   1 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/net/pch_gbe/pch_gbe_main.c 
b/drivers/net/pch_gbe/pch_gbe_main.c
index eac3c5c..e7412f2 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -1701,6 +1701,12 @@ int pch_gbe_up(struct pch_gbe_adapter *adapter)
struct pch_gbe_rx_ring *rx_ring = adapter->rx_ring;
int err;

+   /* Ensure we have a valid MAC */
+   if (!is_valid_ether_addr(adapter->hw.mac.addr)) {
+   pr_err("Error: Invalid MAC address\n");
+   return -EINVAL;
+   }
+
/* hardware has been reset, we need to reload some things */
pch_gbe_set_multi(netdev);

@@ -2392,9 +2398,14 @@ static int pch_gbe_probe(struct pci_dev *pdev,

memcpy(netdev->dev_addr, adapter->hw.mac.addr, netdev->addr_len);
if (!is_valid_ether_addr(netdev->dev_addr)) {
-   dev_err(&pdev->dev, "Invalid MAC Address\n");
-   ret = -EIO;
-   goto err_free_adapter;
+   /*
+* If the MAC is invalid (or just missing), display a warning
+* but do not abort setting up the device. pch_gbe_up will
+* prevent the interface from being brought up until a valid MAC
+* is set.
+*/
+   dev_err(&pdev->dev, "Invalid MAC address, "
+   "interface disabled.\n");
}
setup_timer(&adapter->watchdog_timer, pch_gbe_watchdog,
(unsigned long)adapter);


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




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

Re: [yocto] [PATCH][linux-yocto] pch_gbe: Do not abort probe on bad MAC

[Bruce Ashfield]

On 12-01-24 01:28 AM, Bruce Ashfield wrote:

On 12-01-23 7:26 PM, Darren Hart wrote:



On 01/22/2012 08:01 PM, Bruce Ashfield wrote:

On 12-01-19 4:34 PM, Darren Hart wrote:

Bruce, please apply to linux-yocto-3.0/yocto/standard/base


Queued.


I don't see this in the repository yet, is it still pending? I'm trying
to write a BSP that is dependent on it.'


It's queued with the rest of my 3.0 updates. I've been spending
time on 3.2 and haven't pushed these out yet.


FYI: You can see this in the 3.0 kernel repo now, I fetched davem's
net repo and cherry-picked it in. The SRCREV update will follow once
I've merged 3.0.18 (or .17 if .18 takes too long).

Cheers,

Bruce



Bruce



Thanks,

Darren



Bruce



Upstream-Status: Accepted (Linux 3.3)

If the MAC is invalid or not implemented, do not abort the probe. Issue
a warning and prevent bringing the interface up until a MAC is set
manually
(via ifconfig $IFACE hw ether $MAC).

Tested on two platforms, one with a valid MAC, the other without a
MAC. The real
MAC is used if present, the interface fails to come up until the MAC
is set on
the other. They successfully get an IP over DHCP and pass a simple
ping and
login over ssh test.

This is meant to allow the Inforce SYS940X development board:
http://www.inforcecomputing.com/SYS940X_ECX.html
(and others suffering from a missing MAC) to work with the mainline
kernel.
Without this patch, the probe will fail and the interface will not
be created,
preventing the user from configuring the MAC manually.

This does not make any attempt to address a missing or invalid MAC
for the
pch_phub driver.

Signed-off-by: Darren Hart
CC: Arjan van de Ven
CC: Alan Cox
CC: Tomoya MORINAGA
CC: Jeff Kirsher
CC: "David S. Miller"
CC: Paul Gortmaker
CC: Jon Mason
CC: net...@vger.kernel.org
CC: Mark Brown
CC: David Laight
CC: Joe Perches
---
drivers/net/pch_gbe/pch_gbe_main.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/net/pch_gbe/pch_gbe_main.c
b/drivers/net/pch_gbe/pch_gbe_main.c
index eac3c5c..e7412f2 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -1701,6 +1701,12 @@ int pch_gbe_up(struct pch_gbe_adapter *adapter)
struct pch_gbe_rx_ring *rx_ring = adapter->rx_ring;
int err;

+ /* Ensure we have a valid MAC */
+ if (!is_valid_ether_addr(adapter->hw.mac.addr)) {
+ pr_err("Error: Invalid MAC address\n");
+ return -EINVAL;
+ }
+
/* hardware has been reset, we need to reload some things */
pch_gbe_set_multi(netdev);

@@ -2392,9 +2398,14 @@ static int pch_gbe_probe(struct pci_dev *pdev,

memcpy(netdev->dev_addr, adapter->hw.mac.addr, netdev->addr_len);
if (!is_valid_ether_addr(netdev->dev_addr)) {
- dev_err(&pdev->dev, "Invalid MAC Address\n");
- ret = -EIO;
- goto err_free_adapter;
+ /*
+ * If the MAC is invalid (or just missing), display a warning
+ * but do not abort setting up the device. pch_gbe_up will
+ * prevent the interface from being brought up until a valid MAC
+ * is set.
+ */
+ dev_err(&pdev->dev, "Invalid MAC address, "
+ "interface disabled.\n");
}
setup_timer(&adapter->watchdog_timer, pch_gbe_watchdog,
(unsigned long)adapter);


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




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


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

Re: [yocto] [PATCH 0/2][KERNEL] new yocto/emgd-1.10 feature branch

[Bruce Ashfield]

On 12-01-25 03:30 PM, Tom Zanussi wrote:

On Tue, 2012-01-10 at 15:50 -0500, Bruce Ashfield wrote:

On 12-01-02 02:31 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

This patchset adds a new yocto/emgd-1.10 feature branch to linux-yocto-3.0,
alongside the existing yocto/emgd branch containing emgd-1.8.

Bruce, please don't merge this yet though - it depends on the new emgd-1.10
recipe, which in turn depends on some new LICENSE_FLAGS functionality being
merged.  Will let you know when all that's taken care of and it's safe to
pull this in.


Just pinging. I assume these are safe to merge now ?



Hi Bruce,

Safe now, please merge at your convenience.


Thanks Tom, I'm doing 3.0.x updates + 3.2 right now, so I'll
roll this into that update. ETA tomorrow.

Bruce



Thanks,

Tom


Bruce



Thanks,

Tom

The following changes since commit 6b4bf6173b0bd2d1619a8218bac66ebc4681dd35:
Maurice Ma (1):
  x86, efi: Convert efi_phys_get_time() args to physical addresses

are available in the git repository at:

git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git 
tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0

Tom Zanussi (2):
yocto/emgd: emgd 1.10 driver
yocto/emgd: initial build fixups

   drivers/gpu/drm/Kconfig|9 +
   drivers/gpu/drm/Makefile   |1 +
   drivers/gpu/drm/emgd/Makefile  |  294 +
   drivers/gpu/drm/emgd/emgd/cfg/config.h |  113 +
   drivers/gpu/drm/emgd/emgd/cfg/config_default.h |  198 +
   drivers/gpu/drm/emgd/emgd/cfg/config_helper.c  |  244 +
   .../gpu/drm/emgd/emgd/core/init/cmn/igd_global.c   |   34 +
   drivers/gpu/drm/emgd/emgd/core/init/cmn/igd_init.c |  918 +++
   .../drm/emgd/emgd/core/init/cmn/init_dispatch.h|   65 +
   drivers/gpu/drm/emgd/emgd/core/init/plb/init_plb.c |  458 ++
   .../drm/emgd/emgd/core/init/plb/micro_init_plb.c   |  631 ++
   drivers/gpu/drm/emgd/emgd/core/init/tnc/init_tnc.c |  621 ++
   .../drm/emgd/emgd/core/init/tnc/micro_init_tnc.c   |  992 +++
   drivers/gpu/drm/emgd/emgd/display/dsp/cmn/dsp.c| 2368 +++
   .../drm/emgd/emgd/display/dsp/cmn/dsp_dispatch.h   |   64 +
   .../gpu/drm/emgd/emgd/display/dsp/plb/dsp_plb.c|  709 ++
   .../gpu/drm/emgd/emgd/display/dsp/tnc/dsp_tnc.c|  542 ++
   .../gpu/drm/emgd/emgd/display/mode/cmn/igd_mode.c  | 2219 +++
   drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.c | 1347 
   drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.h |   59 +
   .../drm/emgd/emgd/display/mode/cmn/micro_mode.c| 1744 +
   .../drm/emgd/emgd/display/mode/cmn/mode_dispatch.h |  383 ++
   .../gpu/drm/emgd/emgd/display/mode/cmn/vga_mode.c  | 1467 +
   .../drm/emgd/emgd/display/mode/plb/clocks_plb.c|  701 ++
   .../drm/emgd/emgd/display/mode/plb/kms_mode_plb.c  | 1102 
   .../emgd/emgd/display/mode/plb/micro_mode_plb.c| 1372 
   .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.c  | 1932 ++
   .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.h  |   47 +
   .../drm/emgd/emgd/display/mode/tnc/clocks_tnc.c| 1180 
   .../drm/emgd/emgd/display/mode/tnc/kms_mode_tnc.c  | 1721 +
   .../emgd/emgd/display/mode/tnc/micro_mode_tnc.c| 2643 
   .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.c  | 1997 ++
   .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.h  |   52 +
   drivers/gpu/drm/emgd/emgd/display/pd/cmn/pd.c  |  516 ++
   .../gpu/drm/emgd/emgd/display/pi/cmn/displayid.c   | 1058 +++
   drivers/gpu/drm/emgd/emgd/display/pi/cmn/edid.c| 1187 
   .../drm/emgd/emgd/display/pi/cmn/i2c_dispatch.h|   78 +
   drivers/gpu/drm/emgd/emgd/display/pi/cmn/igd_pi.c  |  260 +
   .../gpu/drm/emgd/emgd/display/pi/cmn/mode_table.c  | 2545 
   .../gpu/drm/emgd/emgd/display/pi/cmn/pd_init_all.c |  215 +
   drivers/gpu/drm/emgd/emgd/display/pi/cmn/pi.c  | 1883 ++
   drivers/gpu/drm/emgd/emgd/display/pi/plb/i2c_plb.c |  940 +++
   .../drm/emgd/emgd/display/pi/tnc/i2c_bitbash_tnc.c |  599 ++
   .../drm/emgd/emgd/display/pi/tnc/i2c_gmbus_tnc.c   |  929 +++
   drivers/gpu/drm/emgd/emgd/drm/drm_emgd_private.h   |  167 +
   drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c |  512 ++
   drivers/gpu/drm/emgd/emgd/drm/emgd_crtc.c  | 1004 +++
   drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c   | 2399 +++
   drivers/gpu/drm/emgd/emgd/drm/emgd_drv.h   |  199 +
   drivers/gpu/drm/emgd/emgd/drm/emgd_encoder.c   |  474 ++
   drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c| 1403 
   drivers/gpu/drm/emgd/emgd/drm/emgd_fbcon.c |  801 +++
   drivers/gpu/drm/emgd/emgd/drm/emgd_interface.c | 2583 
   drivers/gpu/drm/emgd/emgd/drm/emgd_mmap.c  |  186 +
   drivers/gpu/drm/emgd/emgd/drm/emgd_test_pvrsrv.c   | 1365 
   drivers/gpu/drm/emgd/emgd/drm/im

Re: [yocto] Request to enable SMP and virtio for qemux86/x86-64

[Bruce Ashfield]

On 12-01-17 9:06 AM, Bruce Ashfield wrote:

On 12-01-12 08:14 AM, Zhai, Edwin wrote:

Bruce,
Thanks for your efforts!


FYI: I haven't forgotten about this, I'm just reworking a few
things with the 3.2 kernel tree, and will include this as part
of that effort. It will all be available soon.


FYI: I've been testing this with both an updated 3.0 and 3.2 kernel
for the 1.2 release and it seems to cause no issues.

I've made the changes in the repos, and when my 1.2 pull request
comes out for these two trees (in the next day or so), this will be
done.

Cheers,

Bruce



Bruce



Edwin

On 2012/1/11 20:43, Bruce Ashfield wrote:

On 12-01-11 02:01 AM, Zhai, Edwin wrote:

Bruce,
Can we enable SMP and virtio by default for qemux86/x86-64? This can
achieve
huge perf boost for workload inside qemu. E.g. we enabled self-hosted
image,
where we build yocto inside qemu.

Attached patch showes the kernel config option.

Is it reasonable?


It should be. I just need to look at the fallback modes, and how this
impacts different host systems. That being said, I've run with similar
configs in the past (depending on the workload) with no issues.

qemux8-64 is already SMP, so it would just need the addition of virtio
devices, which just means we'd look at this as any BSP/target config
update.

But with graceful degradation (i.e maxcpus with SMP set) and agreement
that we'd like to simulate SMP by default, then we can make the change
and I'll merge it into the base config for the target and pull it into
the kernel tree.

Cheers,

Bruce






Thanks,
Edwin







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


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

Re: [yocto] [PATCH 0/2][KERNEL] new yocto/emgd-1.10 feature branch

[Bruce Ashfield]

On 12-01-02 02:31 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

This patchset adds a new yocto/emgd-1.10 feature branch to linux-yocto-3.0,
alongside the existing yocto/emgd branch containing emgd-1.8.

Bruce, please don't merge this yet though - it depends on the new emgd-1.10
recipe, which in turn depends on some new LICENSE_FLAGS functionality being
merged.  Will let you know when all that's taken care of and it's safe to
pull this in.


These are merged in with my 3.0.18 update to the kernel. I'm
doing build tests, and this will be available shortly.

Bruce



Thanks,

Tom

The following changes since commit 6b4bf6173b0bd2d1619a8218bac66ebc4681dd35:
   Maurice Ma (1):
 x86, efi: Convert efi_phys_get_time() args to physical addresses

are available in the git repository at:

   git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git 
tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0
   
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=tzanussi/linux-yocto-3.0-yocto/emgd-1.10.v0

Tom Zanussi (2):
   yocto/emgd: emgd 1.10 driver
   yocto/emgd: initial build fixups

  drivers/gpu/drm/Kconfig|9 +
  drivers/gpu/drm/Makefile   |1 +
  drivers/gpu/drm/emgd/Makefile  |  294 +
  drivers/gpu/drm/emgd/emgd/cfg/config.h |  113 +
  drivers/gpu/drm/emgd/emgd/cfg/config_default.h |  198 +
  drivers/gpu/drm/emgd/emgd/cfg/config_helper.c  |  244 +
  .../gpu/drm/emgd/emgd/core/init/cmn/igd_global.c   |   34 +
  drivers/gpu/drm/emgd/emgd/core/init/cmn/igd_init.c |  918 +++
  .../drm/emgd/emgd/core/init/cmn/init_dispatch.h|   65 +
  drivers/gpu/drm/emgd/emgd/core/init/plb/init_plb.c |  458 ++
  .../drm/emgd/emgd/core/init/plb/micro_init_plb.c   |  631 ++
  drivers/gpu/drm/emgd/emgd/core/init/tnc/init_tnc.c |  621 ++
  .../drm/emgd/emgd/core/init/tnc/micro_init_tnc.c   |  992 +++
  drivers/gpu/drm/emgd/emgd/display/dsp/cmn/dsp.c| 2368 +++
  .../drm/emgd/emgd/display/dsp/cmn/dsp_dispatch.h   |   64 +
  .../gpu/drm/emgd/emgd/display/dsp/plb/dsp_plb.c|  709 ++
  .../gpu/drm/emgd/emgd/display/dsp/tnc/dsp_tnc.c|  542 ++
  .../gpu/drm/emgd/emgd/display/mode/cmn/igd_mode.c  | 2219 +++
  drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.c | 1347 
  drivers/gpu/drm/emgd/emgd/display/mode/cmn/match.h |   59 +
  .../drm/emgd/emgd/display/mode/cmn/micro_mode.c| 1744 +
  .../drm/emgd/emgd/display/mode/cmn/mode_dispatch.h |  383 ++
  .../gpu/drm/emgd/emgd/display/mode/cmn/vga_mode.c  | 1467 +
  .../drm/emgd/emgd/display/mode/plb/clocks_plb.c|  701 ++
  .../drm/emgd/emgd/display/mode/plb/kms_mode_plb.c  | 1102 
  .../emgd/emgd/display/mode/plb/micro_mode_plb.c| 1372 
  .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.c  | 1932 ++
  .../gpu/drm/emgd/emgd/display/mode/plb/mode_plb.h  |   47 +
  .../drm/emgd/emgd/display/mode/tnc/clocks_tnc.c| 1180 
  .../drm/emgd/emgd/display/mode/tnc/kms_mode_tnc.c  | 1721 +
  .../emgd/emgd/display/mode/tnc/micro_mode_tnc.c| 2643 
  .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.c  | 1997 ++
  .../gpu/drm/emgd/emgd/display/mode/tnc/mode_tnc.h  |   52 +
  drivers/gpu/drm/emgd/emgd/display/pd/cmn/pd.c  |  516 ++
  .../gpu/drm/emgd/emgd/display/pi/cmn/displayid.c   | 1058 +++
  drivers/gpu/drm/emgd/emgd/display/pi/cmn/edid.c| 1187 
  .../drm/emgd/emgd/display/pi/cmn/i2c_dispatch.h|   78 +
  drivers/gpu/drm/emgd/emgd/display/pi/cmn/igd_pi.c  |  260 +
  .../gpu/drm/emgd/emgd/display/pi/cmn/mode_table.c  | 2545 
  .../gpu/drm/emgd/emgd/display/pi/cmn/pd_init_all.c |  215 +
  drivers/gpu/drm/emgd/emgd/display/pi/cmn/pi.c  | 1883 ++
  drivers/gpu/drm/emgd/emgd/display/pi/plb/i2c_plb.c |  940 +++
  .../drm/emgd/emgd/display/pi/tnc/i2c_bitbash_tnc.c |  599 ++
  .../drm/emgd/emgd/display/pi/tnc/i2c_gmbus_tnc.c   |  929 +++
  drivers/gpu/drm/emgd/emgd/drm/drm_emgd_private.h   |  167 +
  drivers/gpu/drm/emgd/emgd/drm/emgd_connector.c |  512 ++
  drivers/gpu/drm/emgd/emgd/drm/emgd_crtc.c  | 1004 +++
  drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c   | 2399 +++
  drivers/gpu/drm/emgd/emgd/drm/emgd_drv.h   |  199 +
  drivers/gpu/drm/emgd/emgd/drm/emgd_encoder.c   |  474 ++
  drivers/gpu/drm/emgd/emgd/drm/emgd_fb.c| 1403 
  drivers/gpu/drm/emgd/emgd/drm/emgd_fbcon.c |  801 +++
  drivers/gpu/drm/emgd/emgd/drm/emgd_interface.c | 2583 
  drivers/gpu/drm/emgd/emgd/drm/emgd_mmap.c  |  186 +
  drivers/gpu/drm/emgd/emgd/drm/emgd_test_pvrsrv.c   | 1365 
  drivers/gpu/drm/emgd/emgd/drm/image_data.h |   33 +
  drivers/gpu/drm/emgd/emgd/drm/splash_screen.c  | 2221 +++
  drivers/gpu/drm/emgd/emgd/drm/splash_screen.h  |  280 +
  drivers/gpu/drm/emgd/emgd/drm/user_config.c|  252 +
  drivers/gpu/drm/emgd/emgd/drm/user_config.h|  113 +
  drivers/gpu/drm/emgd/emgd/gmm/gmm.c  

Re: [yocto] [PATCH 0/1][KERNEL] meta/crownbay: use new yocto/emgd-1.10 feature branch

[Bruce Ashfield]

On 12-01-02 02:31 PM, tom.zanu...@intel.com wrote:

From: Tom Zanussi

This patchset makes crownbay use the new yocto/emgd-1.10 feature branch.

Bruce, please don't merge this yet though - it depends on the new emgd-1.10
recipe, which in turn depends on some new LICENSE_FLAGS functionality being
merged.  Will let you know when all that's taken care of and it's safe to
pull this in.


merged with the emgd changes. Build testing now.

Bruce



Thanks,

Tom

The following changes since commit c979f1365b1eb74e882b2cbbc8407ec536ab6eb8:
   Bruce Ashfield (1):
 meta/routstationpro: refresh for 3.0 + rt support

are available in the git repository at:

   git://git.yoctoproject.org/linux-yocto-2.6.37-contrib.git 
tzanussi/linux-yocto-3.0-meta/emgd-1.10.v0
   
http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/linux-yocto-3.0-meta/emgd-1.10.v0

Tom Zanussi (1):
   crownbay: use emgd-1.10

  meta/cfg/kernel-cache/bsp/crownbay/crownbay.scc |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)



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

Re: [yocto] Understanding the git commits for Yocto and meta

[Bruce Ashfield]

On Sat, Jan 28, 2012 at 9:51 AM, James Abernathy  wrote:
> While I've read enough to think I understand git, I get confused when it's
> applied to real situations like Yocto.  If I look at the Yocto Development
> Manual, Appendix A, A.5.2.4 Changing Recipes-kernel, It brings up some
> questions.
>
> 1. The way I see it, when you guys commit something to the linux yocto
> master or meta there is a commit string associated with that commit.  Not to
> any certain branch of the git repository, right?

I'm not following your terminology. There's a git has that is used to
update the SRCREVs
for bitbake, but that hash is always on the meta branch. Bitbake likes
git hashes, but the
kernel build infrastructure talks branches .. since humans can
remember branches, but
not git hashes.

>
> 2.  So if I'm building an image for atom-pc using Edison branch, the first
> SRCREV I'm interested in is yocto/standard/common-pc/atom-pc branch.  But
> the commits I see at
>
>  http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/commit/?h=yocto/standard/common-pc/atom-pc
>
> are commits not associated with Edison, but Master, right?

They are all just commits on the board branch. edison has a snapshot
in time the SRCREV
that is used. Master marches on, but the commits that were current in
the timeframe of edison,
will always be there.

>
> 3.  How do I find the commit string for a particular branch, like Edison,
> for something like yocto/standard/common-pc/atom-pc?

I'm not following the terminology again. Maybe if you describe what
you are trying to
achieve ? git will tell you what branch has any commit .. just use git
branch --contains 

>
> 4.  To me, branches are things like Edison, Bernard, etc.  But on the page:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/refs/heads?h=yocto/standard/common-pc/atom-pc
>
> yocto/standard/common-pc/atom-pc, master, and meta are all listed as
> branches.  What is the difference??

edison and bernard are yocto branches. The kernel is a separate
repository and can actually be
used standalone (which I do). It has branches for it's meta data and
to isolate board changes.
A particular kernel repository is referenced by the yocto kernel
recipes. They are what follow the
yocto branches .. not the kernel itself.

>
> 5.  The second SRCREV seems to be associated with meta.  How does that
> relate to my whole confusion on branches.

A board build is composed of two things the meta data (configuration,
patches) that
describe the BSP and the actual code changes (the board branch).

>
> 6.  To me, if you are working with Edison and a particular BSP, then these 2
> commit strings should be constant forever, right?

Yes, for the official / known BSP. If you do local work, you can of
course have your
own tree and advance both.

Cheers,

Bruce

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



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 1/1] meta/beagleboard: Using CONFIG_PANEL_GENERIC_DPI=y

[Bruce Ashfield]

On Sat, Jan 28, 2012 at 8:57 PM,   wrote:
> From: Jingdong Lu 
>
> Using CONFIG_PANEL_GENERIC_DPI=y instead of CONFIG_PANEL_GENERIC=y
> for beagleboard.

I've got this one queued in the next 3.0 update.

Cheers,

Bruce

>
> Signed-off-by: Jingdong Lu 
> ---
>  .../kernel-cache/bsp/beagleboard/beagleboard.cfg   |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/meta/cfg/kernel-cache/bsp/beagleboard/beagleboard.cfg 
> b/meta/cfg/kernel-cache/bsp/beagleboard/beagleboard.cfg
> index 994e034..8bb9d87 100644
> --- a/meta/cfg/kernel-cache/bsp/beagleboard/beagleboard.cfg
> +++ b/meta/cfg/kernel-cache/bsp/beagleboard/beagleboard.cfg
> @@ -216,7 +216,7 @@ CONFIG_FB_OMAP2_NUM_FBS=2
>  #
>  # OMAP2/3 Display Device Drivers
>  #
> -CONFIG_PANEL_GENERIC=y
> +CONFIG_PANEL_GENERIC_DPI=y
>  CONFIG_PANEL_SHARP_LS037V7DW01=y
>  # CONFIG_PANEL_LGPHILIPS_LB035Q02 is not set
>  # CONFIG_PANEL_SAMSUNG_LTE430WQ_F0C is not set
> --
> 1.7.0.4
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Understanding the git commits for Yocto and meta

[Bruce Ashfield]

On Sun, Jan 29, 2012 at 7:00 AM, James Abernathy  wrote:
>
> On Jan 28, 2012, at 6:25 PM, Bruce Ashfield wrote:
>
> On Sat, Jan 28, 2012 at 9:51 AM, James Abernathy 
> wrote:
>
> While I've read enough to think I understand git, I get confused when it's
>
> applied to real situations like Yocto.  If I look at the Yocto Development
>
> Manual, Appendix A, A.5.2.4 Changing Recipes-kernel, It brings up some
>
> questions.
>
>
> 1. The way I see it, when you guys commit something to the linux yocto
>
> master or meta there is a commit string associated with that commit.  Not to
>
> any certain branch of the git repository, right?
>
>
> I'm not following your terminology. There's a git has that is used to
> update the SRCREVs
> for bitbake, but that hash is always on the meta branch. Bitbake likes
> git hashes, but the
> kernel build infrastructure talks branches .. since humans can
> remember branches, but
> not git hashes.
>
>
> I'm sure I'm not using the terminology right because, I clearly don't
> understand the whole concept yet.  That light bulb has not gone on yet. :-)

The quoting is all messed up in my copy of the email, so apologies if I miss
something on my reply!

>
> Basically, I see from a user perspective that you start the process with
> creating a clone of the Yocto Project files
> repository, git://git.yoctoproject.org/poky, and you also create a clone of
> the meta-intel BSP repository if you are working with the Intel board BSPs.
>  I have on occasion also cloned the Yocto Linux Kernel and poky extra so I
> could do the Appendix B example.  In the examples and my testing, I've
> always checked out the edison branch of both the yocto project files in the
> poky directory and the edison branch in the meta-intel directory.  So in my
> primitive  thinking, my branch is edison.  By examining Appendix B, I see
> where they checkout a branch of the Yocto Linux kernel called,
> common-pc-base, using the command, git checkout -b common-pc-base
> origin/yocto/standard/common-pc/base.  But once changes are made you commit
> those changes to the local bare clone that will be used in the build
> process.  So I think I see that to get the right versions of the Yocto Linux
> Kernel, I need to tell bitbake to use a particular branch called
> yocto/standard/common-pc/base.  I think the KMACHINE parameter does this in

It's less "version" and more "right branch for my machine", using the
repository that
was current / specified in the yocto release you are working from.
i.e. edison had
2.6.37 and 3.0 kernels, and the meta/recipes-kernel/linux/linux-yocto*
recipes point
to the right repositories that are known to work for that release, and
the recipes specify
the SRCREVs for the machine and meta branches.

> the Appendix B example.  However, in the App. B example, there is no talk
> about SRCREV anywhere.

That's all correct. The appendix examples typically have a setup that
uses AUTOREV
during local kernel development. This means that you don't need to do
SRCREV updates
to see you changes. If you weren't working with AUTOREV, you would need to have
SRCREV updates in a bbappend in the layer of your choice.

> Relating Appendix A recipes-kernel SRCREV to Appendix B example is a problem
> for me.
>
>
>
> 2.  So if I'm building an image for atom-pc using Edison branch, the first
>
> SRCREV I'm interested in is yocto/standard/common-pc/atom-pc branch.  But
>
> the commits I see at
>
>
>  http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/commit/?h=yocto/standard/common-pc/atom-pc
>
>
> are commits not associated with Edison, but Master, right?

They are associated with the 3.0  kernel development. master points at
certain SRCREVs, older
releases have SRCREVs that mark where we tested them. Also note that
as development marches
on for a given kernel version it is done in such a way that the older
release continues to work, with
the same machine branches, just building different points in those
branches (the SRCREVs). If we
add functionality to a kernel that isn't appropriate for a point
release (i.e. 1.1.1) then a maintenance
copy of the repository is created, and the point release branch
recipes are updated to point to that
repository.

>
>
> They are all just commits on the board branch. edison has a snapshot
> in time the SRCREV
> that is used. Master marches on, but the commits that were current in
> the timeframe of edison,
> will always be there.

Exactly.

>
>
> So here is a terminology problem in my mind.
>  yocto/standard/common-pc/atom-pc seems to be a branch in the meta-intel
> repository.  edison seems to be both a snapshot and branch of poky
> repository.???

Rich