Re: [oe] State of the art for creating an image that you can dd to an SD card

2014-06-26 Thread Denys Dmytriyenko 
On Thu, Jun 26, 2014 at 04:46:17PM -0700, Philip Balister wrote:
> On 06/26/2014 04:43 PM, Denys Dmytriyenko wrote:
> > On Thu, Jun 26, 2014 at 01:12:41PM -0700, Ash Charles wrote:
> >> On Thu, Jun 26, 2014 at 12:28 PM, Philip Balister  
> >> wrote:
> >>> Ones with a really ancient MLO, I think. Hopefully, all of those
> >>> binaries are gone from the Internet now.
> >>>
> >>> Philip
> >>
> >> Excellent---thanks.  I had assumed this was boot ROM dependent, not
> >> MLO dependent!
> > 
> > It is BootROM, not MLO...
> > 
> 
> How old are these parts? I'm assuming they are not easily found in the
> wild anymore.

OMAP35xx (3503/3530) was released in 2008, which was a respin of mobile 
OMAP34xx, and was used in Classic BeagleBoard...

http://en.wikipedia.org/wiki/BeagleBoard

-- 
Denys
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] State of the art for creating an image that you can dd to an SD card

2014-06-26 Thread Ash Charles 
On Thu, Jun 26, 2014 at 4:50 PM, Denys Dmytriyenko  wrote:
> Definitely OMAP34xx/35xx family. I'm not very sure if OMAP36xx/37xx had a
> fixed BootROM already, but probably it had, as Beagleboard xM was much more
> forgiving to SD card format, IIRC...
This matches my experience.  Unfortunately, we still have a lot of
customers using OM35xx parts so I'd better not take the CHS stuff out
of our instructions just yet.
--Ash
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] State of the art for creating an image that you can dd to an SD card

2014-06-26 Thread Denys Dmytriyenko 
On Thu, Jun 26, 2014 at 12:23:35PM -0700, Ash Charles wrote:
> On Thu, Jun 26, 2014 at 11:09 AM, Denys Dmytriyenko  wrote:
> > "CHS business", as Philip called it, was only partially required in the 
> > early
> > days of OMAP3 SoCs few years ago, due to some "specific" FAT implementation 
> > of
> > the BootROM. These days it's not required on modern Sitara SoCs.
> Which OMAP3 SOCs need the CHS business?

Definitely OMAP34xx/35xx family. I'm not very sure if OMAP36xx/37xx had a 
fixed BootROM already, but probably it had, as Beagleboard xM was much more 
forgiving to SD card format, IIRC...

-- 
Denys
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] State of the art for creating an image that you can dd to an SD card

2014-06-26 Thread Philip Balister 
On 06/26/2014 04:43 PM, Denys Dmytriyenko wrote:
> On Thu, Jun 26, 2014 at 01:12:41PM -0700, Ash Charles wrote:
>> On Thu, Jun 26, 2014 at 12:28 PM, Philip Balister  
>> wrote:
>>> Ones with a really ancient MLO, I think. Hopefully, all of those
>>> binaries are gone from the Internet now.
>>>
>>> Philip
>>
>> Excellent---thanks.  I had assumed this was boot ROM dependent, not
>> MLO dependent!
> 
> It is BootROM, not MLO...
> 

How old are these parts? I'm assuming they are not easily found in the
wild anymore.

Philip
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] State of the art for creating an image that you can dd to an SD card

2014-06-26 Thread Denys Dmytriyenko 
On Thu, Jun 26, 2014 at 01:12:41PM -0700, Ash Charles wrote:
> On Thu, Jun 26, 2014 at 12:28 PM, Philip Balister  wrote:
> > Ones with a really ancient MLO, I think. Hopefully, all of those
> > binaries are gone from the Internet now.
> >
> > Philip
> 
> Excellent---thanks.  I had assumed this was boot ROM dependent, not
> MLO dependent!

It is BootROM, not MLO...

-- 
Denys
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] Installing RPM packages in SDK sysroot

2014-06-26 Thread Adam Lee 
Hello everyone, in the section 4.2. Configuring the PMS of the Yocto ADT
manual, it describes adding packages to a target sysroot using OPKG. This
method works well as documented. However my choice of package manager is
Yocto's default - RPM. And I was not able to successfully install RPM
packages in the SDK sysroot.

Ultimately, I think installing RPM packages using SmartPM fails because the
list of installed packages is not included in the SDK sysroot. A deployable
image contains a file called Packages in /var/lib/rpm. The SDK sysroot does
not have this file and shows 0 installed packages when I run `smart stats`.
Note that when I am using OPKG instead of RPM, I have the equivalent
package index file in /var/lib/opkg/lists for both sysroot and deployable
images.

I can still attempt to install a package, but it quite literally wants to
rebuild the entire rootfs. For example, running `smart install opencv-dev`
warns that it has to install 400 packages. These packages include
base-files, bash, m4, make, python-dev etc.

So this makes me think that either RPM is not supported in SDK sysroot or
the feature is incomplete. It's also possible that I have missed an
important detail.

I will be looking into the sdk class and the package manager class to see
what's really happening. In the meanwhile I'd appreciate if someone can
provide some pointers!

Thanks,

Adam
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] State of the art for creating an image that you can dd to an SD card

2014-06-26 Thread Diego Sueiro 
Denys,

On Thu, Jun 26, 2014 at 3:09 PM, Denys Dmytriyenko  wrote:

> "CHS business", as Philip called it, was only partially required in the
> early
> days of OMAP3 SoCs few years ago, due to some "specific" FAT
> implementation of
> the BootROM. These days it's not required on modern Sitara SoCs.
>

So it could be true for am3517 of 3 years ago.


Regards,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br


/*long live rock 'n roll*/
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] State of the art for creating an image that you can dd to an SD card

2014-06-26 Thread Ash Charles 
On Thu, Jun 26, 2014 at 12:28 PM, Philip Balister  wrote:
> Ones with a really ancient MLO, I think. Hopefully, all of those
> binaries are gone from the Internet now.
>
> Philip

Excellent---thanks.  I had assumed this was boot ROM dependent, not
MLO dependent!
--Ash
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] State of the art for creating an image that you can dd to an SD card

2014-06-26 Thread Philip Balister 
On 06/26/2014 12:23 PM, Ash Charles wrote:
> On Thu, Jun 26, 2014 at 11:09 AM, Denys Dmytriyenko  wrote:
>> "CHS business", as Philip called it, was only partially required in the early
>> days of OMAP3 SoCs few years ago, due to some "specific" FAT implementation 
>> of
>> the BootROM. These days it's not required on modern Sitara SoCs.
> Which OMAP3 SOCs need the CHS business?

Ones with a really ancient MLO, I think. Hopefully, all of those
binaries are gone from the Internet now.

Philip

> 
> --Ash
> 
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] State of the art for creating an image that you can dd to an SD card

2014-06-26 Thread Ash Charles 
On Thu, Jun 26, 2014 at 11:09 AM, Denys Dmytriyenko  wrote:
> "CHS business", as Philip called it, was only partially required in the early
> days of OMAP3 SoCs few years ago, due to some "specific" FAT implementation of
> the BootROM. These days it's not required on modern Sitara SoCs.
Which OMAP3 SOCs need the CHS business?

--Ash
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] State of the art for creating an image that you can dd to an SD card

2014-06-26 Thread Denys Dmytriyenko 
On Wed, Jun 25, 2014 at 08:45:50PM -0300, Diego Sueiro wrote:
> Hi Philip,
> 
> On Wed, Jun 25, 2014 at 8:27 PM, Philip Balister 
> wrote:
> 
> > On 06/25/2014 04:13 PM, Diego Sueiro wrote:
> > > Hi Denys,
> > >
> > > On Wed, Jun 25, 2014 at 3:55 PM, Denys Dmytriyenko 
> > wrote:
> > >
> > >> http://cgit.openembedded.org/openembedded-core/tree/scripts/wic
> > >>
> > >> But indeed, better documentation would be most appreciated.
> > >
> > >
> > > I didn't have a chance to take a look and test wic tool.
> > > Do you know if it can be used to generate sdcard images for TI's Sitara
> > > SoCs?
> > > The _problem_ for creating a sdcard image for Sitara is the configuration
> > > of Heads, Sectors and Cylinders that should be passed to sfdisk and needs
> > > to be done as root.
> >
> > This isn't true.
> >
> > https://groups.google.com/forum/#!topic/beagleboard/ro5k5r4Cuq4
> >
> > I've avoided the CHS business for ages and haven't had trouble booting
> 
> 
> Thanks for the link.
> 
> About 3 yeas ago I have issues with this using an industrial 2GB uSD from
> Delkin Devices with am3517. And as far as I remember I just got it working
> with CHS configuration.
> 
> I'm going to test it again with a Sandisk uSD and am3359 to see if it
> remains. But I don't have a Delkin uSD and am3517 anymore :(

"CHS business", as Philip called it, was only partially required in the early 
days of OMAP3 SoCs few years ago, due to some "specific" FAT implementation of 
the BootROM. These days it's not required on modern Sitara SoCs.

-- 
Denys
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] State of the art for creating an image that you can dd to an SD card

2014-06-26 Thread Denys Dmytriyenko 
On Wed, Jun 25, 2014 at 03:04:31PM -0400, Brian Hutchinson wrote:
> On Wed, Jun 25, 2014 at 2:38 PM, Philip Balister  wrote:
> > On 06/25/2014 03:07 AM, Paul Eggleton wrote:
> >> On Tuesday 24 June 2014 16:14:58 Philip Balister wrote:
> >>> What's the best available solution for creating an image you can dd to
> >>> an SD card? It seems like this wheel has been invented several times and
> >>> I am wondering if people are converging on one approach.
> >>>
> >>> Bonus points for resizing the linux partition.
> >>>
> >>> How are people doing this today?
> >>
> >> I think wic has seen some uptake and enhancement since its introduction a
> >> couple of releases ago. It has certainly worked for me in writing SD cards 
> >> for
> >> Galileo. We seem to be a bit short on documentation for it though...
> >
> > Googling for "wic sd" doesn't help. I've seen some commits, so I'll take
> > a look in the meta data.
> >
> > Philip
> 
> I think he's talking about:
> http://patchwork.openembedded.org/patch/59059/
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=3847

A lot of good info is hidden in those 2 obscure places! :)
How about copying all that to a Wiki page for starters?

-- 
Denys
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH] cpuburn-neon: Upgrade to 2014066 version to fix build break

2014-06-26 Thread Lauren Post 
Replace SRC_URI with new location, md5sum and new name since previous download
will not work.  Without this fix cpuburn-neon has a broken build.

Signed-off-by: Lauren Post 
Signed-off-by: Otavio Salvador 
---
 ...n-neon_20120610.bb => cpuburn-neon_20140626.bb} |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)
 rename meta-oe/recipes-benchmark/cpuburn/{cpuburn-neon_20120610.bb => 
cpuburn-neon_20140626.bb} (72%)

diff --git a/meta-oe/recipes-benchmark/cpuburn/cpuburn-neon_20120610.bb 
b/meta-oe/recipes-benchmark/cpuburn/cpuburn-neon_20140626.bb
similarity index 72%
rename from meta-oe/recipes-benchmark/cpuburn/cpuburn-neon_20120610.bb
rename to meta-oe/recipes-benchmark/cpuburn/cpuburn-neon_20140626.bb
index 8ec5e95..ed1f1ee 100644
--- a/meta-oe/recipes-benchmark/cpuburn/cpuburn-neon_20120610.bb
+++ b/meta-oe/recipes-benchmark/cpuburn/cpuburn-neon_20140626.bb
@@ -8,17 +8,18 @@ DL_DIR_append = "/${PN}-${PV}"
 COMPATIBLE_MACHINE = "(${@bb.utils.contains("TUNE_FEATURES", "neon", 
"${MACHINE}", "Invalid!", d)})"
 
 SRC_URI = "http://hardwarebug.org/files/burn.S;name=mru \
-   
http://github.com/downloads/ssvb/ssvb.github.com/ssvb-cpuburn-a8.S;name=ssvb";
+   
https://github.com/ssvb/cpuburn-arm/raw/master/cpuburn-a8.S;name=ssvb";
+
 SRC_URI[mru.md5sum] = "823abc72c2cd448e87df9bc5355a4456"
 SRC_URI[mru.sha256sum] = 
"01d9fc04f83740c513c25401dcc89c11b2a5a6013e70bfca42b7b02129f88cd2"
-SRC_URI[ssvb.md5sum] = "0acc570d943c41c7f8602b9ff6fa111d"
-SRC_URI[ssvb.sha256sum] = 
"bfddd3226a499ffdf71bb58c05ccdc6dac5bb2c2c3bdb10ac610ee0b60aac087"
+SRC_URI[ssvb.md5sum] = "ba0ef2939a3b3b487523448c67544e94"
+SRC_URI[ssvb.sha256sum] = 
"ce42ebdc71c876a33d9f7534355ef76cefa0d00ddb19ad69cf05a266c861d08d"
 
 S = "${WORKDIR}"
 
 do_compile() {
 ${CC} ${CFLAGS} ${LDFLAGS} burn.S -o burn
-${CC} ${CFLAGS} ${LDFLAGS} ssvb-cpuburn-a8.S -o burn-neona8
+${CC} ${CFLAGS} ${LDFLAGS} cpuburn-a8.S -o burn-neona8
 }
 
 do_install() {
-- 
1.7.9.5

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [PATCH] libeigen: remove obsolete setting for default out-of-tree build

2014-06-26 Thread Lukas Bulwahn 
Since commit 783fb88f@openembedded-core, out-of-tree builds of
cmake-based recipes are the default, and the variables
OECMAKE_BUILDPATH and OECMAKE_SOURCEPATH were deprecated.

With the commit 2c23d7ab@openembedded-core, the variable
OECMAKE_SOURCEPATH was put back into action, but this causes the
libeigen recipe to fail as OECMAKE_SOURCEPATH is set in the
recipe, but OECMAKE_BUILDPATH is set to the bbclass default.

This commit simply removes both variables from the libeigen recipe
and hence sets the recipe to do a default out-of-tree build.
This resolves the build failure of libeigen with
2c23d7ab@openembedded-core, and furthermore, the adjusted recipe
still works with the cmake.bbclass of 783fb88f@openembedded-core.

The build failure was discovered during the regression testing of
the meta-ros layer. The exact build error message and its
investigation is recorded in issue #276 of the meta-ros issue
tracker at https://github.com/bmwcarit/meta-ros/issues/276.

Signed-off-by: Lukas Bulwahn 
---
 meta-oe/recipes-support/libeigen/libeigen_3.2.0.bb | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta-oe/recipes-support/libeigen/libeigen_3.2.0.bb 
b/meta-oe/recipes-support/libeigen/libeigen_3.2.0.bb
index 4183f05..de5186f 100644
--- a/meta-oe/recipes-support/libeigen/libeigen_3.2.0.bb
+++ b/meta-oe/recipes-support/libeigen/libeigen_3.2.0.bb
@@ -13,9 +13,6 @@ S = "${WORKDIR}/eigen-eigen-ffa86ffb5570"
 
 inherit cmake
 
-OECMAKE_SOURCEPATH = ".."
-OECMAKE_BUILDPATH = "build"
-
 EXTRA_OECMAKE += "-Dpkg_config_libdir=${libdir}"
 
 FILES_${PN} = "${includedir} ${libdir}"
-- 
1.9.3

-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel