From: Tom Zanussi <tom.zanussi@...>

The meta-intel BSPs currently have a number of machine settings common
to all - factor these out into a couple common include files.

Signed-off-by: Tom Zanussi <tom.zanussi@...>
---
common/common-bsp-mach.inc | 13 +++++++++++++
common/common-bsp-x.inc | 4 ++++
2 files changed, 17 insertions(+), 0 deletions(-)
create mode 100644 common/common-bsp-mach.inc
create mode 100644 common/common-bsp-x.inc

diff --git a/common/common-bsp-mach.inc b/common/common-bsp-mach.inc
new file mode 100644
index 0000000..b020a84
--- /dev/null
+++ b/common/common-bsp-mach.inc
@@ -0,0 +1,13 @@
+MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 \
+ acpi serial usbgadget"
+
+KERNEL_IMAGETYPE = "bzImage"
+
+SERIAL_CONSOLE = "115200 ttyS0"
+
+MACHINE_EXTRA_RRECOMMENDS = "kernel-modules eee-acpi-scripts"
+
+IMAGE_FSTYPES ?= "ext3 cpio.gz"
+
+GLIBC_ADDONS = "nptl"
+GLIBC_EXTRA_OECONF = "--with-tls"
diff --git a/common/common-bsp-x.inc b/common/common-bsp-x.inc
new file mode 100644
index 0000000..c012efd
--- /dev/null
+++ b/common/common-bsp-x.inc
@@ -0,0 +1,4 @@
+PREFERRED_PROVIDER_virtual/libx11 ?= "libx11-trim"
+PREFERRED_PROVIDER_virtual/libgl ?= "mesa-dri"
+PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xf86-dri-lite"
+PREFERRED_PROVIDER_virtual/xserver-xf86 ?= "xserver-xf86-dri-lite"
--
1.7.0.4

From: Tom Zanussi <tom.zanussi@...>

The meta-intel BSPs have some common settings - this just moves
them out int separate .inc files to simplify them and ease
maintenance.

I compiled and boot-tested into graphics using sato-live images
for each, with the exception of fishriver (I accidentally pulled
out a cable so can't boot into graphics at the moment) and
crownbay-noemgd (same as crownbay, pretty much).

I also didn't touch n450, since it's already factored out and
simplified.

The following changes since commit 92fc07a5f1b98779806cdcc2341487ff5ea5a238:
Dexuan Cui (1):
emenlow: fix some .bbappend files' name: poky -> core, etc.

are available in the git repository at:

git://git.yoctoproject.org/meta-intel.git tzanussi/mach-cleanup
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/mach-cleanup

Tom Zanussi (6):
meta-intel: add a couple common .inc files
meta-sugarbay: use common .inc files
meta-crownbay: use common .inc files
meta-fishriver: use common .inc files
meta-jasperforest: use common .inc files
meta-emenlow: use common .inc files

common/common-bsp-mach.inc | 13 +++++++++++++
common/common-bsp-x.inc | 4 ++++
meta-crownbay/conf/machine/crownbay-noemgd.conf | 19 ++-----------------
meta-crownbay/conf/machine/crownbay.conf | 19 ++-----------------
meta-emenlow/conf/machine/emenlow.conf | 17 ++---------------
meta-fishriver/conf/machine/fishriver.conf | 20 +++-----------------
meta-jasperforest/conf/machine/jasperforest.conf | 22 +++-------------------
meta-sugarbay/conf/machine/sugarbay.conf | 22 +++-------------------
8 files changed, 32 insertions(+), 104 deletions(-)
create mode 100644 common/common-bsp-mach.inc
create mode 100644 common/common-bsp-x.inc

just so i'm doing this the right way, what is the appropriate way to
report bitbake fetch errors? with a fully-updated git repo, i just
ran:

$ bitbake -c fetchall -k core-image-sato

and got fetch errors for both of:

* sat-solver
* linux-libc-headers

should i post the more detailed output of the command? the contents
of the log files? etc, etc.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

I do have two branches (master and Bernard) in my yocto-docs contrib area. The master branch is used for updates to the upcoming release and is in various states of correctness/completeness. I guess I will need to take the time to do a push for every change I make to my local copy of yocto-docs master.

The docs that are on the website are Bernard only until we release.

ScottR

On Thu, 2011-07-14 at 19:10 -0400, Robert P. J. Day wrote:

On Thu, 14 Jul 2011, Joshua Lock wrote:

As I understand it documentation repository updates are reflected on
the website so the docs tend to reflect the released version.

It would be nice to be able to provide development & release
documentation but I can't see it happening any time soon.

ok, that explains it but it doesn't defend it. IMHO, any single
versioned tarball or repository checkout should always be internally
consistent, and that includes embedded documentation. when i do a
"git pull" of any software, i expect the contents of any docs/
directory to reflect what's there.

if you want to publicly publish the docs that reflect the last
official release, then build those docs from the appropriate git tag.

I agree that the docs in master should reflect the code in master and
that the docs on the bernard branch should be the ones which make the
bernard references.

Which or both can end up on the website as needed which is a separate
issue.

I thought this had been fixed and Scott had two branches so what's going
wrong? :/

Cheers,

Richard

On Thu, 14 Jul 2011, Joshua Lock wrote:

As I understand it documentation repository updates are reflected on
the website so the docs tend to reflect the released version.

It would be nice to be able to provide development & release
documentation but I can't see it happening any time soon.

ok, that explains it but it doesn't defend it. IMHO, any single
versioned tarball or repository checkout should always be internally
consistent, and that includes embedded documentation. when i do a
"git pull" of any software, i expect the contents of any docs/
directory to reflect what's there.

if you want to publicly publish the docs that reflect the last
official release, then build those docs from the appropriate git tag.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On Thu, 2011-07-14 at 18:01 -0400, Robert P. J. Day wrote:

On Thu, 14 Jul 2011, Rifenbark, Scott M wrote:

Robert,

My understanding was that the target for this sample command could
not be 'core-image-sato' for the QS version on the website, which
supports Bernard. Maybe someone out there has a bit more
information on details to your question.

ScottR

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Robert P. J. Day
Sent: Thursday, July 14, 2011 2:32 PM
To: Yocto discussion list
Subject: [yocto] why does quick start guide refer to non-provided "poky-image-sato"?


maybe i'm misreading something, but the yocto QS guide provides the
sample command:

$ bitbake -k poky-image-sato

however, nothing provides that target. i can see the git log entry:

commit 1947b17478187bb623da74484747e470ce42d206
Author: Scott Rifenbark <scott.m.rifenbark@...>
Date: Tue May 10 12:50:36 2011 -0500

documentation/yocto-project-qs/yocto-project-qs.xml: changed build command

The command used in the example to build an image was using
'bitbake core-image-sato', which is only available in master and
not Bernard. So, I changed the command to be 'bitbake poky-image-sato'
at Dave Stewart's request. He located and pointed out the error.

(From yocto-docs rev: 3fa83550aaec5a3549825814a77fa7a823a2daea)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@...>
Signed-off-by: Richard Purdie <richard.purdie@...>

but it seems that "core-image-sato" is perfectly valid, at least at
the moment. clarification?

currently, scripts/oe-setup-builddir lists one of the common targets
as "core-image-sato", so certainly *something* is out of sync.

As I understand it documentation repository updates are reflected on the
website so the docs tend to reflect the released version.

It would be nice to be able to provide development & release
documentation but I can't see it happening any time soon.

Joshua
--
Joshua Lock
Yocto Project "Johannes Factotum"
Intel Open Source Technology Centre

From: Yinghai Lu <yinghai@...>

commit 8f389a99b652aab5b42297280bd94d95933ad12f upstream.

Stefan found nobootmem does not work on his system that has only 8M of
RAM. This causes an early panic:

BIOS-provided physical RAM map:
BIOS-88: 0000000000000000 - 000000000009f000 (usable)
BIOS-88: 0000000000100000 - 0000000000840000 (usable)
bootconsole [earlyser0] enabled
Notice: NX (Execute Disable) protection missing in CPU or disabled in BIOS!
DMI not present or invalid.
last_pfn = 0x840 max_arch_pfn = 0x100000
init_memory_mapping: 0000000000000000-0000000000840000
8MB LOWMEM available.
mapped low ram: 0 - 00840000
low ram: 0 - 00840000
Zone PFN ranges:
DMA 0x00000001 -> 0x00001000
Normal empty
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000001 -> 0x0000009f
0: 0x00000100 -> 0x00000840
BUG: Int 6: CR2 (null)
EDI c034663c ESI (null) EBP c0329f38 ESP c0329ef4
EBX c0346380 EDX 00000006 ECX ffffffff EAX fffffff4
err (null) EIP c0353191 CS c0320060 flg 00010082
Stack: (null) c030c533 000007cd (null) c030c533 00000001 (null) (null)
00000003 0000083f 00000018 00000002 00000002 c0329f6c c03534d6 (null)
(null) 00000100 00000840 (null) c0329f64 00000001 00001000 (null)
Pid: 0, comm: swapper Not tainted 2.6.36 #5
Call Trace:
[<c02e3707>] ? 0xc02e3707
[<c035e6e5>] 0xc035e6e5
[<c0353191>] ? 0xc0353191
[<c03534d6>] 0xc03534d6
[<c034f1cd>] 0xc034f1cd
[<c034a824>] 0xc034a824
[<c03513cb>] ? 0xc03513cb
[<c0349432>] 0xc0349432
[<c0349066>] 0xc0349066

It turns out that we should ignore the low limit of 16M.

Use alloc_bootmem_node_nopanic() in this case.

[akpm@...: less mess]
Signed-off-by: Yinghai LU <yinghai@...>
Reported-by: Stefan Hellermann <stefan@...>
Tested-by: Stefan Hellermann <stefan@...>
Cc: Ingo Molnar <mingo@...>
Cc: "H. Peter Anvin" <hpa@...>
Cc: Thomas Gleixner <tglx@...>
Cc: <stable@...> [2.6.34+]
Signed-off-by: Andrew Morton <akpm@...>
Signed-off-by: Linus Torvalds <torvalds@...>

Applied to linux-yocto-2.6.37

Signed-off-by: Darren Hart <dvhart@...>
---
include/linux/bootmem.h | 2 ++
mm/page_alloc.c | 7 ++++---
2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
index 499dfe9..552875f 100644
--- a/include/linux/bootmem.h
+++ b/include/linux/bootmem.h
@@ -115,6 +115,8 @@ extern void *__alloc_bootmem_low_node(pg_data_t *pgdat,
__alloc_bootmem_nopanic(x, PAGE_SIZE, __pa(MAX_DMA_ADDRESS))
#define alloc_bootmem_node(pgdat, x) \
__alloc_bootmem_node(pgdat, x, SMP_CACHE_BYTES, __pa(MAX_DMA_ADDRESS))
+#define alloc_bootmem_node_nopanic(pgdat, x) \
+ __alloc_bootmem_node_nopanic(pgdat, x, SMP_CACHE_BYTES, __pa(MAX_DMA_ADDRESS))
#define alloc_bootmem_pages_node(pgdat, x) \
__alloc_bootmem_node(pgdat, x, PAGE_SIZE, __pa(MAX_DMA_ADDRESS))
#define alloc_bootmem_pages_node_nopanic(pgdat, x) \
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b8b32aa..1c28e48 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3464,7 +3464,7 @@ int zone_wait_table_init(struct zone *zone, unsigned long zone_size_pages)

if (!slab_is_available()) {
zone->wait_table = (wait_queue_head_t *)
- alloc_bootmem_node(pgdat, alloc_size);
+ alloc_bootmem_node_nopanic(pgdat, alloc_size);
} else {
/*
* This case means that a zone whose size was 0 gets new memory
@@ -4037,7 +4037,8 @@ static void __init setup_usemap(struct pglist_data *pgdat,
unsigned long usemapsize = usemap_size(zonesize);
zone->pageblock_flags = NULL;
if (usemapsize)
- zone->pageblock_flags = alloc_bootmem_node(pgdat, usemapsize);
+ zone->pageblock_flags = alloc_bootmem_node_nopanic(pgdat,
+ usemapsize);
}
#else
static void inline setup_usemap(struct pglist_data *pgdat,
@@ -4203,7 +4204,7 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat)
size = (end - start) * sizeof(struct page);
map = alloc_remap(pgdat->node_id, size);
if (!map)
- map = alloc_bootmem_node(pgdat, size);
+ map = alloc_bootmem_node_nopanic(pgdat, size);
pgdat->node_mem_map = map + (pgdat->node_start_pfn - start);
}
#ifndef CONFIG_NEED_MULTIPLE_NODES
--
1.7.1

From: Darren Hart <dvhart@...>

The following patch from mainline addresses an issues that prevented my
qemu testing from booting in less than 17M of memory. With this page,
the kernel can boot to init in 8M of memory.

Apply to yocto/standard/base

The following changes since commit bb8e31f2c99f5e007660d4540df246fb7ecfa746:

USB: ehci: remove structure packing from ehci_def (2011-06-22 14:23:26 -0400)

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

Yinghai Lu (1):
mm: use alloc_bootmem_node_nopanic() on really needed path

include/linux/bootmem.h | 2 ++
mm/page_alloc.c | 7 ++++---
2 files changed, 6 insertions(+), 3 deletions(-)

Robert,

What release of Yocto Project are you using?

Scott

On Thu, 14 Jul 2011, Rifenbark, Scott M wrote:

Robert,

My understanding was that the target for this sample command could
not be 'core-image-sato' for the QS version on the website, which
supports Bernard. Maybe someone out there has a bit more
information on details to your question.

ScottR

-----Original Message-----
From: yocto-bounces@... [mailto:yocto-bounces@...] On Behalf Of Robert P. J. Day
Sent: Thursday, July 14, 2011 2:32 PM
To: Yocto discussion list
Subject: [yocto] why does quick start guide refer to non-provided "poky-image-sato"?


maybe i'm misreading something, but the yocto QS guide provides the
sample command:

$ bitbake -k poky-image-sato

however, nothing provides that target. i can see the git log entry:

commit 1947b17478187bb623da74484747e470ce42d206
Author: Scott Rifenbark <scott.m.rifenbark@...>
Date: Tue May 10 12:50:36 2011 -0500

documentation/yocto-project-qs/yocto-project-qs.xml: changed build command

The command used in the example to build an image was using
'bitbake core-image-sato', which is only available in master and
not Bernard. So, I changed the command to be 'bitbake poky-image-sato'
at Dave Stewart's request. He located and pointed out the error.

(From yocto-docs rev: 3fa83550aaec5a3549825814a77fa7a823a2daea)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@...>
Signed-off-by: Richard Purdie <richard.purdie@...>

but it seems that "core-image-sato" is perfectly valid, at least at
the moment. clarification?

currently, scripts/oe-setup-builddir lists one of the common targets
as "core-image-sato", so certainly *something* is out of sync.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

Robert,

My understanding was that the target for this sample command could not be 'core-image-sato' for the QS version on the website, which supports Bernard. Maybe someone out there has a bit more information on details to your question.

ScottR

maybe i'm misreading something, but the yocto QS guide provides the
sample command:

$ bitbake -k poky-image-sato

however, nothing provides that target. i can see the git log entry:

commit 1947b17478187bb623da74484747e470ce42d206
Author: Scott Rifenbark <scott.m.rifenbark@...>
Date: Tue May 10 12:50:36 2011 -0500

documentation/yocto-project-qs/yocto-project-qs.xml: changed build command

The command used in the example to build an image was using
'bitbake core-image-sato', which is only available in master and
not Bernard. So, I changed the command to be 'bitbake poky-image-sato'
at Dave Stewart's request. He located and pointed out the error.

(From yocto-docs rev: 3fa83550aaec5a3549825814a77fa7a823a2daea)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@...>
Signed-off-by: Richard Purdie <richard.purdie@...>

but it seems that "core-image-sato" is perfectly valid, at least at
the moment. clarification?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On Thu, 2011-07-14 at 16:56 -0400, Bruce Ashfield wrote:

On 07/14/11 12:34, Kumar Gala wrote:

On Jul 14, 2011, at 11:24 AM, Bruce Ashfield wrote:

On 07/14/11 12:21, Koen Kooi wrote:

Op 14 jul 2011, om 18:20 heeft Kumar Gala het volgende geschreven:

On Jul 14, 2011, at 8:56 AM, Bruce Ashfield wrote:

On 07/14/11 09:40, Koen Kooi wrote:

Op 14 jul 2011, om 15:13 heeft Bruce Ashfield het volgende geschreven:

On 07/14/11 09:05, Kumar Gala wrote:

Is there a list of which IMAGE_FSTYPES are supported. I didn't see anything in the docs. Looking to see if a u-boot 'mkimage' wrapped set of images is supported or not.

I'm not 100% where the list is, but I can confirm that
uImages are supported and work nicely. Assuming that
you are talking about the common use case, and not something
more exotic :)

I think he means partitioned uimages where you have a kernel + initrd in a single uimage. We don't support that *yet*, but all the needed blocks are there. And we finally get a usecase for having the loadadresses in the machine.conf files :)

Yah, that's what I wondered as well. I've done this locally,
but nothing out of the box .. so I had nagging doubts!

Cheers,

Bruce

What's the IMAGE_FSTYPE for a normal uImage ?

None, it's built by the kernel class, not the rootfs class.

and to expand a bit, the machine conf would have:

KERNEL_IMAGETYPE = "uImage"

So the kernel class will build and produce a uImage for deployment.

Ah, so there isnt support for getting a ramdisk wrapped via mkimage.

Correct, or at least not that I've used out of the box, and
this is what Koen was commenting on.

I think we have all the pieces there but someone would have to connect
them up...

Cheers,

Richard

On 07/14/11 12:34, Kumar Gala wrote:

On Jul 14, 2011, at 11:24 AM, Bruce Ashfield wrote:

On 07/14/11 12:21, Koen Kooi wrote:

Op 14 jul 2011, om 18:20 heeft Kumar Gala het volgende geschreven:

On Jul 14, 2011, at 8:56 AM, Bruce Ashfield wrote:

On 07/14/11 09:40, Koen Kooi wrote:

Op 14 jul 2011, om 15:13 heeft Bruce Ashfield het volgende geschreven:

On 07/14/11 09:05, Kumar Gala wrote:

Is there a list of which IMAGE_FSTYPES are supported. I didn't see anything in the docs. Looking to see if a u-boot 'mkimage' wrapped set of images is supported or not.

I'm not 100% where the list is, but I can confirm that
uImages are supported and work nicely. Assuming that
you are talking about the common use case, and not something
more exotic :)

I think he means partitioned uimages where you have a kernel + initrd in a single uimage. We don't support that *yet*, but all the needed blocks are there. And we finally get a usecase for having the loadadresses in the machine.conf files :)

Yah, that's what I wondered as well. I've done this locally,
but nothing out of the box .. so I had nagging doubts!

Cheers,

Bruce

What's the IMAGE_FSTYPE for a normal uImage ?

None, it's built by the kernel class, not the rootfs class.

and to expand a bit, the machine conf would have:

KERNEL_IMAGETYPE = "uImage"

So the kernel class will build and produce a uImage for deployment.

Ah, so there isnt support for getting a ramdisk wrapped via mkimage.

Correct, or at least not that I've used out of the box, and
this is what Koen was commenting on.

Cheers,

Bruce

- k

On Thu, 2011-07-14 at 20:09 +0200, Koen Kooi wrote:

Op 14 jul 2011, om 19:09 heeft Joshua Lock het volgende geschreven:

On Thu, 2011-07-14 at 11:34 -0500, Kumar Gala wrote:

On Jul 14, 2011, at 8:52 AM, Richard Purdie wrote:

On Thu, 2011-07-14 at 08:06 -0500, Kumar Gala wrote:

On Jul 12, 2011, at 3:43 AM, Richard Purdie wrote:

On Mon, 2011-07-11 at 10:00 -0700, Turner Randy wrote:

Hello list,

Is there a interactive menu-based configuration for yocto/poky builds
similar to that provided in Buildroot? Or is someone working on this?

At present there is not any interactive menu based configuration but
there is work ongoing on a UI called hob which allows you to select
packages and construct images of those packages so its a graphical front
end to the system.

We're also in the process of starting to better markup configuration
variables in the metadata so that writing some kind of menu based
configuration system would be easier in the future.

We're certainly open to any help in those areas too!

Cheers,

Richard

Are there any docs for hob at this point?

Not specifically. "bitbake -u hob" should let you see where things are
at. Please keep in mind that its under active development at the moment
and can be considered "alpha" quality but feedback is welcome.

Are they thread of email discussion or anything. I tried playing with it, but a little confused on exactly what its trying to accomplish and what the 'cfg' that is saved off ends up being.

If you have questions please ask them. The saved file should be a recipe
for building a custom image. The purpose of the tool is to help you put
together a custom image and build it.

Try this:

bitbake -u hob

-> Python traceback

change PARALLEL_MAKE from 'j8' to 'j 8'

Ugh, sorry. Bug #1244 to track
http://bugzilla.pokylinux.org/show_bug.cgi?id=1244

bitbake -u hob

click save

Open up recipe in editor

-> 'require None.bb'

So it looks like creating an image from scratch doesn't work.

Yeah, I sucked at designing use cases. This is already filed as bug
#1239 http://bugzilla.pokylinux.org/show_bug.cgi?id=1239

Thanks for the feedback,
Joshua
--
Joshua Lock
Yocto Project "Johannes Factotum"
Intel Open Source Technology Centre

Op 14 jul 2011, om 19:09 heeft Joshua Lock het volgende geschreven:

On Thu, 2011-07-14 at 11:34 -0500, Kumar Gala wrote:

On Jul 14, 2011, at 8:52 AM, Richard Purdie wrote:

On Thu, 2011-07-14 at 08:06 -0500, Kumar Gala wrote:

On Jul 12, 2011, at 3:43 AM, Richard Purdie wrote:

On Mon, 2011-07-11 at 10:00 -0700, Turner Randy wrote:

Hello list,

Is there a interactive menu-based configuration for yocto/poky builds
similar to that provided in Buildroot? Or is someone working on this?

At present there is not any interactive menu based configuration but
there is work ongoing on a UI called hob which allows you to select
packages and construct images of those packages so its a graphical front
end to the system.

We're also in the process of starting to better markup configuration
variables in the metadata so that writing some kind of menu based
configuration system would be easier in the future.

We're certainly open to any help in those areas too!

Cheers,

Richard

Are there any docs for hob at this point?

Not specifically. "bitbake -u hob" should let you see where things are
at. Please keep in mind that its under active development at the moment
and can be considered "alpha" quality but feedback is welcome.

Are they thread of email discussion or anything. I tried playing with it, but a little confused on exactly what its trying to accomplish and what the 'cfg' that is saved off ends up being.

If you have questions please ask them. The saved file should be a recipe
for building a custom image. The purpose of the tool is to help you put
together a custom image and build it.

Try this:

bitbake -u hob

-> Python traceback

change PARALLEL_MAKE from 'j8' to 'j 8'

bitbake -u hob

click save

Open up recipe in editor

-> 'require None.bb'

So it looks like creating an image from scratch doesn't work.

regards,

Koen

Fix some obvious typoes in a couple "opkg-cl" commands in the ADT
manual, packages chapter.

Signed-off-by: Robert P. J. Day <rpjday@...>

---

i'm *hoping* i'm reading this correctly. and i'll try to bundle
fixes into larger single patch submissions as long as they're
logically related.

diff --git a/documentation/adt-manual/adt-package.xml b/documentation/adt-manual/adt-package.xml
index 9f982d1..fd52747 100644
--- a/documentation/adt-manual/adt-package.xml
+++ b/documentation/adt-manual/adt-package.xml
@@ -70,8 +70,8 @@
The following command forms should now work:
<literallayout class='monospaced'>
$ opkg-cl –f &lt;conf_file&gt; -o &lt;sysroot-dir&gt; update
- $ opkg-cl –f &lt;cconf_file&gt;> -o &lt;sysroot-dir&gt; --force-overwrite install libglade
- $ opkg-cl –f &lt;cconf_file&gt; -o &lt;sysroot-dir&gt; --force-overwrite install libglade-dbg
+ $ opkg-cl –f &lt;conf_file&gt; -o &lt;sysroot-dir&gt; --force-overwrite install libglade
+ $ opkg-cl –f &lt;conf_file&gt; -o &lt;sysroot-dir&gt; --force-overwrite install libglade-dbg
$ opkg-cl –f &lt;conf_file&gt; -o &lt;sysroot-dir&gt; --force-overwrite install libglade-dev
</literallayout>
</para>

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

On Thu, 2011-07-14 at 11:34 -0500, Kumar Gala wrote:

On Jul 14, 2011, at 8:52 AM, Richard Purdie wrote:

On Thu, 2011-07-14 at 08:06 -0500, Kumar Gala wrote:

On Jul 12, 2011, at 3:43 AM, Richard Purdie wrote:

On Mon, 2011-07-11 at 10:00 -0700, Turner Randy wrote:

Hello list,

Is there a interactive menu-based configuration for yocto/poky builds
similar to that provided in Buildroot? Or is someone working on this?

At present there is not any interactive menu based configuration but
there is work ongoing on a UI called hob which allows you to select
packages and construct images of those packages so its a graphical front
end to the system.

We're also in the process of starting to better markup configuration
variables in the metadata so that writing some kind of menu based
configuration system would be easier in the future.

We're certainly open to any help in those areas too!

Cheers,

Richard

Are there any docs for hob at this point?

Not specifically. "bitbake -u hob" should let you see where things are
at. Please keep in mind that its under active development at the moment
and can be considered "alpha" quality but feedback is welcome.

Are they thread of email discussion or anything. I tried playing with it, but a little confused on exactly what its trying to accomplish and what the 'cfg' that is saved off ends up being.

If you have questions please ask them. The saved file should be a recipe
for building a custom image. The purpose of the tool is to help you put
together a custom image and build it.

Regards,
Joshua
--
Joshua Lock
Yocto Project "Johannes Factotum"
Intel Open Source Technology Centre

Fix missing prompt, missing "git" and break overly long command in
two since it disappears off the page in the PDF output.

Signed-off-by: Robert P. J. Day <rpjday@...>

---

these fixes should be self-evident.

diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml
index 0cb7154..5a0d975 100644
--- a/documentation/kernel-manual/kernel-how-to.xml
+++ b/documentation/kernel-manual/kernel-how-to.xml
@@ -727,7 +727,7 @@ repository.
<para>
Use this command form to push the changes:
<literallayout class='monospaced'>
- git push ssh://&lt;master server&gt;/&lt;path to repo&gt; &lt;local branch&gt;:&lt;remote branch&gt;
+ &gt; git push ssh://&lt;master server&gt;/&lt;path to repo&gt; &lt;local branch&gt;:&lt;remote branch&gt;
</literallayout>
</para>

@@ -736,7 +736,8 @@ repository.
<filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name
in the master repository <filename>//git.mycompany.com/pub/git/kernel-2.6.37</filename>.
<literallayout class='monospaced'>
- &gt; push ssh://git.mycompany.com/pub/git/kernel-2.6.37 yocto/standard/common-pc/base:yocto/standard/common-pc/base
+ &gt; git push ssh://git.mycompany.com/pub/git/kernel-2.6.37 \
+ yocto/standard/common-pc/base:yocto/standard/common-pc/base
</literallayout>
</para>


--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================