On Sun, Jan 3, 2010 at 7:27 AM, Peter Korsgaard wrote:
>> "Wolfgang" == Wolfgang Denk writes:
>
> Hi,
>
> >> No, that would break stuff for the existing users. The existing format
> >> make/file names shouldn't change.
>
> Wolfgang> Well, with this argument you can block all progress and f
On Sun, Jan 3, 2010 at 3:10 AM, Wolfgang Denk wrote:
> Dear Grant Likely,
>
> In message you
> wrote:
>
> Note that the FIT image can also be made to contain a number of DT
> blobs, and selection of a "board profile" then can be used to boot the
> very sane FIT image file on any of the supported
Note that the FIT image can also be made to contain a number of DT
blobs, and selection of a "board profile" then can be used to boot the
very sane FIT image file on any of the supported boards - so FIT
images inherently support multibooting.
I agree with Wolfgang. Additionally, if a FIT ima
Hi Wolfgang,
The "new" FIT image type should become the default, and old "legacy"
images should only be generated upon special request (i. e. if some-
one needs these for compatibility with an old, not yet FIT-aware
version of the boot loader).
Agreed.
What do you think about changing the U-
> "Wolfgang" == Wolfgang Denk writes:
Hi,
>> No, that would break stuff for the existing users. The existing format
>> make/file names shouldn't change.
Wolfgang> Well, with this argument you can block all progress and freeze all
Wolfgang> development to some ancient state.
We only bre
Dear Grant Likely,
In message you
wrote:
>
> As I said in a previous email; I understand the need for certain
> scenarios, but in the general case it is not the mode that I think
> should be encouraged. I don't want to merge additional targets for
> .dtb embedded in the kernel image unless abso
Dear Grant Likely,
In message you
wrote:
>
> > Let's make this "uImage.old" (or "uImage.legacy" similar) and
> > "uImage", then.
>
> I'm not interested in renaming the target name for the current uImage
> format. I think it will cause too much breakage and pain to do so.
We did this before, a
Dear Grant Likely,
In message you
wrote:
>
> > Currently they have to make a "legacy" uImage, manually run the device
> > tree compiler with the proper flags to generate a board-specific .dtb
> > file,
>
> ... or put the .dts files into arch/powerpc/boot/dts and use 'make .=
> dtb'
>
> multip
Dear Peter,
In message <87wrzzpq8c@macbook.be.48ers.dk> you wrote:
>
> Wolfgang> Let's make this "uImage.old" (or "uImage.legacy" similar) and
> Wolfgang> "uImage", then.
>
> No, that would break stuff for the existing users. The existing format
> make/file names shouldn't change.
Well, wi
> "Wolfgang" == Wolfgang Denk writes:
>> What do you think about changing the U-Boot documentation to rename
>> those 2 image types to:
>> 1 uImages
>> 2 FIT Images
Wolfgang> Let's make this "uImage.old" (or "uImage.legacy" similar) and
Wolfgang> "uImage", then.
No, that would break s
On Fri, Jan 1, 2010 at 7:12 AM, Wolfgang Denk wrote:
> Dear Grant,
>
> In message you
> wrote:
>>
>> Thinking further, I do actually have another concern, at least with
>> regard to the way the current patch set implements things. Is it
>> expected or even "recommended" that fit images will *al
On Fri, Jan 1, 2010 at 3:44 AM, Wolfgang Denk wrote:
> Dear Peter,
>
> In message <1262301038.29396.137.ca...@localhost.localdomain> you wrote:
>> What do you think about changing the U-Boot documentation to rename
>> those 2 image types to:
>> 1 uImages
>> 2 FIT Images
>
> Let's make this "uImage
On Thu, Dec 31, 2009 at 3:44 PM, Wolfgang Denk wrote:
> Dear Grant Likely,
>
> In message you
> wrote:
>>
>> IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
>> Makefile so that make behaves more consistently. Speaking of which,
>> the number of '.' in the name is getting rath
Hi Peter,
On Wed, Dec 30, 2009 at 6:10 PM, Peter Tyser wrote:
> On Wed, 2009-12-30 at 17:01 -0700, Grant Likely wrote:
>> On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser wrote:
>> > Hi Grant,
>> > I put U-Boot ML on CC.
>>
>> Thinking further, I do actually have another concern, at least with
>> re
Dear Grant,
In message you
wrote:
>
> Thinking further, I do actually have another concern, at least with
> regard to the way the current patch set implements things. Is it
> expected or even "recommended" that fit images will *always* contain a
> .dtb image? The current patch only handles the
Dear Peter,
In message <1262301038.29396.137.ca...@localhost.localdomain> you wrote:
>
> > Why chose a different name at all? We could still call it "uImage",
> > meaning "U-Boot image" - U-Boot is clever enought o detect
> > automatically if we pass it an old style or a fit image.
>
> I agree w
Hi Wolfgang,
> > IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
> > Makefile so that make behaves more consistently. Speaking of which,
> > the number of '.' in the name is getting rather large. Would you
> > consider using 'fitImage' instead of 'uImage.fit'?
>
> Why chose a
Dear Grant Likely,
In message you
wrote:
>
> IIRC, uImage.fit.initrd.% should appear before uImage.fit.% in the
> Makefile so that make behaves more consistently. Speaking of which,
> the number of '.' in the name is getting rather large. Would you
> consider using 'fitImage' instead of 'uImag
> "Grant" == Grant Likely writes:
Hi,
Grant> Personally, I don't get any benefit out of the new image format,
Grant> so I haven't spent any time looking at it. However, I'm
Grant> concerned about the drift back towards a different image per
Grant> target when the move over the last 4 ye
On Wed, 2009-12-30 at 17:01 -0700, Grant Likely wrote:
> On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser wrote:
> > Hi Grant,
> > I put U-Boot ML on CC.
>
> Thinking further, I do actually have another concern, at least with
> regard to the way the current patch set implements things. Is it
> expec
On Wed, Dec 30, 2009 at 4:39 PM, Peter Tyser wrote:
> Hi Grant,
> I put U-Boot ML on CC.
Thinking further, I do actually have another concern, at least with
regard to the way the current patch set implements things. Is it
expected or even "recommended" that fit images will *always* contain a
.dt
Hi Grant,
I put U-Boot ML on CC.
On Wed, 2009-12-30 at 16:02 -0700, Grant Likely wrote:
> On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser wrote:
> > The PowerPC architecture has the ability to embed the ramdisk located
> > at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image. If
> > t
On Mon, Dec 21, 2009 at 6:50 PM, Peter Tyser wrote:
> The PowerPC architecture has the ability to embed the ramdisk located
> at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image. If
> the bootable kernel is in the Flattened Image Tree (FIT) format, the
> ramdisk should be a node in
The PowerPC architecture has the ability to embed the ramdisk located
at arch/powerpc/boot/ramdisk.image.gz into a bootable kernel image. If
the bootable kernel is in the Flattened Image Tree (FIT) format, the
ramdisk should be a node in the tree instead of being embedded directly
in the kernel ex
24 matches
Mail list logo