On (05/01/12 17:36), autif khan wrote:

On Thu, Jan 5, 2012 at 5:17 PM, Mark Hatle <mark.hatle@...> wrote:

On 1/5/12 3:52 PM, autif khan wrote:

libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
unhandled argument `=/usr/lib/libglib-2.0.la'

The version of libtool you are currently using is damaged in some way.  I
suspect the program is falling back and trying to use either a local version
or the host-system version.

I am using 6.0 Edison release of yocto. Is libtool being broken a
known issue for this version?

nothing is broken. Its the mono package which uses older version of
libtool (pre 2.4) and its trying to link in .la files which are generated by new
libtool 2.4+

your best option is that add the mono recipe to metadata and build it
there instead of building it on target. If you want to build on target
than you have to regenerate its autotools related build configuration

best option is to get the recipes from oe.dev and use them that probably
would work out quicker for you.

-Khem

Hi Mark!

On Fri, Jan 20, 2012 at 6:07 PM, Mark Hatle <mark.hatle@...> wrote:

On 1/20/12 8:07 AM, Andrea Galbusera wrote:

Hi,

In oe-classic there used to be a machine configuration for an i486sx
based machine called vortex86sx. In the past I was successful in
building a running image for such a target. Since I'd like to make a
new system based on vortex, my goal is to leverage the whole Yocto
Project infrastructure and port that old configuration to a BSP layer.
This will save me a lot of time in supporting developers with SDKs and
so.

Since I could not find any BSP based on hardware older than i586 in
recent Yocto trees, I'm concerned about this. Do you know of any
obstacle in doing such a port? I'm mainly interested in building
images with no graphics for that target: core-image-minimal is a
reasonable reference for me.

My plan was to initially lay out a new BSP by following guidelines
from Development Manual and BSP Guide. Then, what I suspect to be a
little trickier for my expertise, is the porting of the original
tune-i486sx.inc file to the current Yocto infrastructure. Is there any
document I can leverage to map the variables defined in the
oe-classic's syntax to the current ones for such a machine
configuration file?

A few things you will need.. a tune file for the CPU, and a tune file for
the machine/bsp... and you'll have to make sure that eglibc/Linux can still
run on that machine.

I know a while back some changes were made to the GNU toolchain, include gcc
to change default optimization levels and such, I don't know if this
negatively impacted the ability to generate i486 compatible code.

The original i486 tune file was defining the following:

TARGET_ARCH = "i486"
TARGET_CC_ARCH = "-march=i486"
PACKAGE_EXTRA_ARCHS = "486sx"
BASE_PACKAGE_ARCH = "486sx"
FEED_ARCH = "${BASE_PACKAGE_ARCH}"

Are they still valid variables? Do I need any more?

Variables have changed.  The following is likely what you want (not tested
of course) meta/conf/machine/include/tune-i486.inc (based off of tune-i586):

DEFAULTTUNE ?= "i486"
TUNE_PKGARCH_TMP = "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86",
"x86_64", d)}"
TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "i486", "i486",
TUNE_PKGARCH_TMP, d)}"

require conf/machine/include/ia32/arch-ia32.inc

# Extra tune features
TUNEVALID[i486] = "Enable i486 specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "i486", "-march=i486",
"", d)}"

# Extra tune selections
AVAILTUNES += "i486"
TUNE_FEATURES_tune-i486 ?= "${TUNE_FEATURES_tune-x86} i486"
BASE_LIB_tune-i486 ?= "lib"
PACKAGE_EXTRA_ARCHS_tune-i486 = "${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486"

I set up the custom layer following your suggestions and it's building
now... By inspecting the logs I see "-march=i486" applied to
compiler's command lines. I won't be able to test the kernel until
next Monday. I will follow up to let you know if it works.

Thanks!
Regards,
Andrea

Agenda
 
* Opens collection - 5 min (Song)
* Yocto 1.1.1 point release update - 10 min (Josh/Beth)
* Yocto 1.2 M2 status, M3 planning status - 10 min (Song/Team)
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.2_Status
* Opens - 10 min 
* Team Sharing - 20 min


-----Original Appointment-----


Conference details
Conference name:
Yocto Technical Team
Conference date/start time:
Tue Jun 28, 2011 at 10:00 AM Central Daylight Time
Participants:
30
Duration:
60 minutes
Participant passcode:
49611427
Dial-in number:
1.972.995.7777
US Toll Free number:
1.877.561.6828
BlackBerry users, click this link to join your conference as a chairperson:
1.972.995.7777x67184230#
BlackBerry users, click this link to join your conference as a participant:
1.972.995.7777x49611427#
 
Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode.

Local and Global Access Numbers


Country
Dial-in number
Australia:
1800 636 843
Czech Republic:
242 430 350
China (Beijing):
From office dial 8-9957777 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai):
From office dial 8-9957777 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen):
From office dial 8-9957777 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities):
From IP phone dial 8-9957777
Other cities - Non IP phone dial 021-23073322
Denmark:
8060 1400
Finland:
09 41333477
France:
0497 275888
Germany:
08161 803232
Holland:
030 2417490
India:
BSNL subscribers use 1800 425 9996 (Toll Free)
Airtel subscribers use 0008 009 861 212 (Toll Free)
From TI Campus use 89957777
Others use 2509 9555 (Landline within Bangalore) or
80 2509 9555 (Outside Bangalore)
Israel:
09 790 6715
Italy:
039 69061234 (039 is local city code not country code)
Japan:
From TI Campus use 8 995 7777
Outside TI use 03 4331 3777
Malaysia:
From IP phone dial 2643799
From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799
Norway:
2 295 8744
Philippines:
From Baguio City use 4471177
From Metro Manila area use 8702477
Singapore:
From IP phone dial 3894777
Outside TI use 6389 4777
South Korea:
From IP phone dial 5606998
From Seoul dial 5606998
Outside Seoul dial (02)5606998
Sweden:
08 58755577
Taiwan:
From IP phone dial 1363
From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363
Turkey:
Landline Only dial 0811 288 0001
then enter 877 633 1123
UK:
01604 663003
US:
972 995 7777 or 1877 561 6828

Recurring conferences
First scheduled conference:
Tue Jun 28, 2011
Recurrence frequency:
Weekly - Every 1 week(s) on Tuesday
Recurrence ends:
End on Fri Jun 22, 2012, 10:40 AM CDT

Jim Abernathy
On Jan 20, 2012, at 1:00 PM, autif khan <autif.mlist@...> wrote:

On Fri, Jan 20, 2012 at 12:15 PM, Paul Eggleton
<paul.eggleton@...> wrote:

On Friday 20 January 2012 11:54:44 autif khan wrote:

Did you file a bug on this?

I have not. I am not sure I should. I am not even sure whoose call it
should be weather or not this goes in README.hardware. I hope someone
chimes in

So I would say if any of our documentation is out-of-date or unclear, it
should be fixed, no deliberation needed :)

However, in Poky master, README.hardware has now been updated to remove
references to the old directdisk images. It could be that we need to
explicitly add something like what you have written about writing the image to
a hard disk, but for the moment it is at least no longer out-of-date.

At the very least a great start would be to put your instructions up as a page
on the Yocto Project wiki.

I have created a new link titled "How Do I" on the main page and for
now, this is the only entry.

Please take a look.

https://wiki.yoctoproject.org/wiki/Main_Page
https://wiki.yoctoproject.org/wiki/How_do_I

Looks good to me.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On Fri, Jan 20, 2012 at 12:15 PM, Paul Eggleton
<paul.eggleton@...> wrote:

On Friday 20 January 2012 11:54:44 autif khan wrote:

Did you file a bug on this?

I have not. I am not sure I should. I am not even sure whoose call it
should be weather or not this goes in README.hardware. I hope someone
chimes in

So I would say if any of our documentation is out-of-date or unclear, it
should be fixed, no deliberation needed :)

However, in Poky master, README.hardware has now been updated to remove
references to the old directdisk images. It could be that we need to
explicitly add something like what you have written about writing the image to
a hard disk, but for the moment it is at least no longer out-of-date.

At the very least a great start would be to put your instructions up as a page
on the Yocto Project wiki.

I have created a new link titled "How Do I" on the main page and for
now, this is the only entry.

Please take a look.

https://wiki.yoctoproject.org/wiki/Main_Page
https://wiki.yoctoproject.org/wiki/How_do_I

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On Friday 20 January 2012 11:54:44 autif khan wrote:

Did you file a bug on this?

I have not. I am not sure I should. I am not even sure whoose call it
should be weather or not this goes in README.hardware. I hope someone
chimes in

So I would say if any of our documentation is out-of-date or unclear, it
should be fixed, no deliberation needed :)

However, in Poky master, README.hardware has now been updated to remove
references to the old directdisk images. It could be that we need to
explicitly add something like what you have written about writing the image to
a hard disk, but for the moment it is at least no longer out-of-date.

At the very least a great start would be to put your instructions up as a page
on the Yocto Project wiki.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

On 1/20/12 8:07 AM, Andrea Galbusera wrote:

Hi,

In oe-classic there used to be a machine configuration for an i486sx
based machine called vortex86sx. In the past I was successful in
building a running image for such a target. Since I'd like to make a
new system based on vortex, my goal is to leverage the whole Yocto
Project infrastructure and port that old configuration to a BSP layer.
This will save me a lot of time in supporting developers with SDKs and
so.

Since I could not find any BSP based on hardware older than i586 in
recent Yocto trees, I'm concerned about this. Do you know of any
obstacle in doing such a port? I'm mainly interested in building
images with no graphics for that target: core-image-minimal is a
reasonable reference for me.

My plan was to initially lay out a new BSP by following guidelines
from Development Manual and BSP Guide. Then, what I suspect to be a
little trickier for my expertise, is the porting of the original
tune-i486sx.inc file to the current Yocto infrastructure. Is there any
document I can leverage to map the variables defined in the
oe-classic's syntax to the current ones for such a machine
configuration file?

A few things you will need.. a tune file for the CPU, and a tune file for the machine/bsp... and you'll have to make sure that eglibc/Linux can still run on that machine.

I know a while back some changes were made to the GNU toolchain, include gcc to change default optimization levels and such, I don't know if this negatively impacted the ability to generate i486 compatible code.

The original i486 tune file was defining the following:

TARGET_ARCH = "i486"
TARGET_CC_ARCH = "-march=i486"
PACKAGE_EXTRA_ARCHS = "486sx"
BASE_PACKAGE_ARCH = "486sx"
FEED_ARCH = "${BASE_PACKAGE_ARCH}"

Are they still valid variables? Do I need any more?

Variables have changed. The following is likely what you want (not tested of course) meta/conf/machine/include/tune-i486.inc (based off of tune-i586):

DEFAULTTUNE ?= "i486"
TUNE_PKGARCH_TMP = "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86", "x86_64", d)}"
TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "i486", "i486", TUNE_PKGARCH_TMP, d)}"

require conf/machine/include/ia32/arch-ia32.inc

# Extra tune features
TUNEVALID[i486] = "Enable i486 specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "i486", "-march=i486", "", d)}"

# Extra tune selections
AVAILTUNES += "i486"
TUNE_FEATURES_tune-i486 ?= "${TUNE_FEATURES_tune-x86} i486"
BASE_LIB_tune-i486 ?= "lib"
PACKAGE_EXTRA_ARCHS_tune-i486 = "${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486"

--Mark

Thank you in advance. Regards,
Andrea
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

Excellent question, Jack - we are working on that this week. No promises, but highly likely!

On Fri, Jan 20, 2012 at 11:13 AM, Jim Abernathy <jfabernathy@...> wrote:

On 01/20/2012 09:16 AM, autif khan wrote:

I have been using core-image-sato and core-image-sato-sdk on the hard
disk on Intel Atom (crownbay in my case).

I perform the following broad steps:

1) have a suitable partition on the disk - say partition #3
2) this partition will show up as sde3 on my host machine and sda3 on the
atom
3) mkfs.ext3 /dev/sde3
4) mount /dev/sde3 /mnt/target
5) mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3
/mnt/target-text3
6) cp -a /mnt/target-ext3/* /mnt/target
7) grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, I copy the following to
/mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
       insmod part_msdos
       insmod ext2
       set root='(hd0,msdos3)'
       linux /boot/bzImage root=/dev/sda3
}


Thats it - this boots for me.

Eventually, when I move to some other media, I will have to
investigate other bootloaders - like syslinux.

All the best, do tell if this works.

This worked fine for me. one typo in step (5) ext3 and not text3, but these
are good instructions.  How do we get them put into the README.hardware
instead of the directdisk section that doesn't work anymore.

Yup, I wrote then off the cuff, I am glad that a typo is the only
error and no major missing steps :-)

I am also glad that these steps worked for you.

Did you file a bug on this?

I have not. I am not sure I should. I am not even sure whoose call it
should be weather or not this goes in README.hardware. I hope someone
chimes in

Thanks,

Jim Abernathy

On Thu, Jan 19, 2012 at 7:51 PM, James Abernathy<jfabernathy@...>
 wrote:

The README.hardware file in the poky directory talks about creating
images
on 2 types of disk for the Atom based PCs like the n450. The one I've
successfully tested is the core-image-sato on a USB key.  I have no luck
with the directdisk method because the image recipe doesn't exist for
core-image-minimal-directdisk or core-image-sato-directdisk.

Is there a way to put Yocto on the hard drive on a Atom PC?

Jim A


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

On 01/20/2012 09:16 AM, autif khan wrote:

I have been using core-image-sato and core-image-sato-sdk on the hard
disk on Intel Atom (crownbay in my case).

I perform the following broad steps:

1) have a suitable partition on the disk - say partition #3
2) this partition will show up as sde3 on my host machine and sda3 on the atom
3) mkfs.ext3 /dev/sde3
4) mount /dev/sde3 /mnt/target
5) mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-text3
6) cp -a /mnt/target-ext3/* /mnt/target
7) grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, I copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}


Thats it - this boots for me.

Eventually, when I move to some other media, I will have to
investigate other bootloaders - like syslinux.

All the best, do tell if this works.

This worked fine for me. one typo in step (5) ext3 and not text3, but these are good instructions. How do we get them put into the README.hardware instead of the directdisk section that doesn't work anymore.

Did you file a bug on this?

Thanks,

Jim Abernathy

On Thu, Jan 19, 2012 at 7:51 PM, James Abernathy<jfabernathy@...> wrote:

The README.hardware file in the poky directory talks about creating images
on 2 types of disk for the Atom based PCs like the n450. The one I've
successfully tested is the core-image-sato on a USB key. I have no luck
with the directdisk method because the image recipe doesn't exist for
core-image-minimal-directdisk or core-image-sato-directdisk.

Is there a way to put Yocto on the hard drive on a Atom PC?

Jim A


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

I have been using core-image-sato and core-image-sato-sdk on the hard
disk on Intel Atom (crownbay in my case).

I perform the following broad steps:

1) have a suitable partition on the disk - say partition #3
2) this partition will show up as sde3 on my host machine and sda3 on the atom
3) mkfs.ext3 /dev/sde3
4) mount /dev/sde3 /mnt/target
5) mount -o loop tmp/deploy/images/core-image-sato-sdk.ext3 /mnt/target-text3
6) cp -a /mnt/target-ext3/* /mnt/target
7) grub-install --recheck --root-directory=/mnt/target /dev/sde

If grub install passed, I copy the following to /mnt/target/boot/grub/grub.cfg

set default="0"
set timeout="30"

menuentry 'Yocto SDK' {
insmod part_msdos
insmod ext2
set root='(hd0,msdos3)'
linux /boot/bzImage root=/dev/sda3
}


Thats it - this boots for me.

Eventually, when I move to some other media, I will have to
investigate other bootloaders - like syslinux.

All the best, do tell if this works.

Hi,

In oe-classic there used to be a machine configuration for an i486sx
based machine called vortex86sx. In the past I was successful in
building a running image for such a target. Since I'd like to make a
new system based on vortex, my goal is to leverage the whole Yocto
Project infrastructure and port that old configuration to a BSP layer.
This will save me a lot of time in supporting developers with SDKs and
so.

Since I could not find any BSP based on hardware older than i586 in
recent Yocto trees, I'm concerned about this. Do you know of any
obstacle in doing such a port? I'm mainly interested in building
images with no graphics for that target: core-image-minimal is a
reasonable reference for me.

My plan was to initially lay out a new BSP by following guidelines
from Development Manual and BSP Guide. Then, what I suspect to be a
little trickier for my expertise, is the porting of the original
tune-i486sx.inc file to the current Yocto infrastructure. Is there any
document I can leverage to map the variables defined in the
oe-classic's syntax to the current ones for such a machine
configuration file?

The original i486 tune file was defining the following:

TARGET_ARCH = "i486"
TARGET_CC_ARCH = "-march=i486"
PACKAGE_EXTRA_ARCHS = "486sx"
BASE_PACKAGE_ARCH = "486sx"
FEED_ARCH = "${BASE_PACKAGE_ARCH}"

Are they still valid variables? Do I need any more?

Thank you in advance. Regards,
Andrea

On 01/20/2012 04:25 AM, Jack Mitchell wrote:

On 19/01/12 19:41, Jeff Osier-Mixon wrote:
Would there be any chance of having these talks recorded? They sound
fantastic but unfortunately I work for a small company based in the UK
and we do not have the funds to ship me all the way out to San Fran.

If you make FOSDEM (www.fosdem.org), Paul Eggleton is talking in the
Embedded room about Yocto and OpenEmbedded
(http://www.fosdem.org/2012/schedule/event/openembedded_yocto_common_core).

OpenEmbedded will have a stand there.

Philip

On 19/01/12 19:41, Jeff Osier-Mixon wrote:

Keep Tuesday, February 14, open. That is the day before the Embedded Linux Conference in Redwood Shores, CA, and it is also the day of the first Yocto Project Developer Day, a full-day opportunity to learn more about the Yocto Project. There will be a beginner-level track as well as an intermediate-level track, both with hands-on labs and access to Yocto Project developers. The best part - this day of training is free of charge.

Registration is limited, so please sign up as soon as possible. More information at:

https://events.linuxfoundation.org/events/embedded-linux-conference/yocto-project-developer-day

Please forward this message to anyone you know who would benefit from learning more about the Yocto Project.

--
Jeff Osier-Mixon http://jefro.net/blog

Yocto Project Community Manager @Intel http://yoctoproject.org

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

Hi Jeff,

Would there be any chance of having these talks recorded? They sound fantastic but unfortunately I work for a small company based in the UK and we do not have the funds to ship me all the way out to San Fran.

Best Regards,
Jack.

Great planning session, kernel team! Thanks for prioritizing and cleaning up the schedule. At the same time, if anyone gets time to work on any items moved to post 1.2, it's always a great thing to put it back on 1.2.

Song

Bruce, please apply to linux-yocto-3.0/yocto/standard/base

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 <dvhart@...>
CC: Arjan van de Ven <arjan@...>
CC: Alan Cox <alan@...>
CC: Tomoya MORINAGA <tomoya.rohm@...>
CC: Jeff Kirsher <jeffrey.t.kirsher@...>
CC: "David S. Miller" <davem@...>
CC: Paul Gortmaker <paul.gortmaker@...>
CC: Jon Mason <jdmason@...>
CC: netdev@...
CC: Mark Brown <broonie@...>
CC: David Laight <David.Laight@...>
CC: Joe Perches <joe@...>
---
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);
--
1.7.6.5
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

On 01/19/2012 12:44 PM, Darren Hart wrote:

On 01/19/2012 05:55 AM, Jim Abernathy wrote:

On 01/18/2012 04:34 PM, Darren Hart wrote:

On 01/18/2012 09:05 AM, Jim Abernathy wrote:

FYI for those wanting to use Soft RAID, make sure you create one very
small primary partition for GRUB2 to put the second part of the
boot-loader in. Can't use the old process.

I strongly recommend using a separate DISK for your OS installation.
Yocto builds are hard on disks, and RAID 0 increases your risk of
failure in exchange for the added performance. I use a small SSD for my
OS disk and a large RAID0 array of spinning disks for /build and another
array for /virt (where my VM images live - easily recreated).

Learned a few things in this process. I appreciate all the help and advice.

1. So we know that at least with Edison, btrfs does not work with bitbake.
2. When I rebuilt the system, this time I put the Linux root directory
on an 80GB SSD. That is where I also have my clone of Linux-Yocto
repository, poky, and download directory , DL_DIR.
3. I have create /build with EXT4 format on a Software RAID 0 (striped)
partition, using 2 separate hard drives, to use as the working
build directory for bitbake. I have a striped swap file on the same
two drives. But with 8GB or RAM, I shouldn't be using that much.

My build times for some of the basic meta-intel BSPs is around 103 minutes.

You may be able to improve upon that with the following in /etc/fstab:

/dev/md0 /build ext4 noauto,noatime,nodiratime,commit=6000 0 2

This reduces the number of writes due to updated access time and
increases the commit interval so it doesn't stall while writing out
every 5 minutes per default.

NOTE: THIS INCREASES YOUR RISK OF DATA LOSS

If your machine goes down during a build, you should plan on formatting
that drive. If you only keep builds on it, they easily recreateable and
you may find the performance boost is worth the risk.

I'll test this out and see. I'm plan on keeping this system on a UPS anyway.

Jim S

https://events.linuxfoundation.org/events/embedded-linux-conference/yocto-project-developer-day

On 01/19/2012 05:55 AM, Jim Abernathy wrote:

On 01/18/2012 04:34 PM, Darren Hart wrote:

On 01/18/2012 09:05 AM, Jim Abernathy wrote:

FYI for those wanting to use Soft RAID, make sure you create one very
small primary partition for GRUB2 to put the second part of the
boot-loader in. Can't use the old process.

I strongly recommend using a separate DISK for your OS installation.
Yocto builds are hard on disks, and RAID 0 increases your risk of
failure in exchange for the added performance. I use a small SSD for my
OS disk and a large RAID0 array of spinning disks for /build and another
array for /virt (where my VM images live - easily recreated).

Learned a few things in this process. I appreciate all the help and advice.

1. So we know that at least with Edison, btrfs does not work with bitbake.
2. When I rebuilt the system, this time I put the Linux root directory
on an 80GB SSD. That is where I also have my clone of Linux-Yocto
repository, poky, and download directory , DL_DIR.
3. I have create /build with EXT4 format on a Software RAID 0 (striped)
partition, using 2 separate hard drives, to use as the working
build directory for bitbake. I have a striped swap file on the same
two drives. But with 8GB or RAM, I shouldn't be using that much.

My build times for some of the basic meta-intel BSPs is around 103 minutes.

You may be able to improve upon that with the following in /etc/fstab:

/dev/md0 /build ext4 noauto,noatime,nodiratime,commit=6000 0 2

This reduces the number of writes due to updated access time and
increases the commit interval so it doesn't stall while writing out
every 5 minutes per default.

NOTE: THIS INCREASES YOUR RISK OF DATA LOSS

If your machine goes down during a build, you should plan on formatting
that drive. If you only keep builds on it, they easily recreateable and
you may find the performance boost is worth the risk.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel