Re: [oe] u-boot ready initrds

2010-03-09 Thread Tom Rini
On Tue, 2010-03-09 at 15:41 +0100, Steffen Sledz wrote: > Tom Rini wrote: [snip] > > That said, mkimage -A arm is bad. UBOOT_ARCH is right, > > Good point. Total agreement. > > > and comes from kernel-arch.bbclass. So, I > > think a full patch would need to add in changes to image.bbclass to >

Re: [oe] u-boot ready initrds

2010-03-09 Thread Martyn Welch
Tom Rini wrote: > On Mon, 2010-03-08 at 08:43 +0100, Steffen Sledz wrote: > >> Steffen Sledz wrote: >> >>> Initrds need to be prepared with mkimage to be usable from u-boot. >>> The following patch introduces an additional IMAGE_FSTYPE .cpio.gz.u-boot >>> for this (at the moment just for hi

Re: [oe] u-boot ready initrds

2010-03-09 Thread Steffen Sledz
Tom Rini wrote: >> Initrds need to be prepared with mkimage to be usable from u-boot. >> The following patch introduces an additional IMAGE_FSTYPE .cpio.gz.u-boot >> for this (at the moment just for hipox machine). >> >> Is this the way it should be done? >> >> Should this better become part of con

Re: [oe] u-boot ready initrds

2010-03-08 Thread Tom Rini
On Mon, 2010-03-08 at 08:43 +0100, Steffen Sledz wrote: > Steffen Sledz wrote: > > Initrds need to be prepared with mkimage to be usable from u-boot. > > The following patch introduces an additional IMAGE_FSTYPE .cpio.gz.u-boot > > for this (at the moment just for hipox machine). > > > > Is this t

Re: [oe] u-boot ready initrds

2010-03-07 Thread Steffen Sledz
Steffen Sledz wrote: > Initrds need to be prepared with mkimage to be usable from u-boot. > The following patch introduces an additional IMAGE_FSTYPE .cpio.gz.u-boot > for this (at the moment just for hipox machine). > > Is this the way it should be done? > > Should this better become part of con

[oe] u-boot ready initrds

2010-03-03 Thread Steffen Sledz
Initrds need to be prepared with mkimage to be usable from u-boot. The following patch introduces an additional IMAGE_FSTYPE .cpio.gz.u-boot for this (at the moment just for hipox machine). Is this the way it should be done? Should this better become part of conf/bitbake.conf? Steffen