On 12/10/2011 03:42 PM, Linus Walleij wrote:
...
> Since this was so convenient I made a patch to attach a DTB
> the same way which was floated on devicetree-discuss:
> http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg07256.html
>
> Nico didn't like that:
> http://www.mail-archiv
On Sat, Dec 10, 2011 at 11:53 PM, Wolfgang Denk wrote:
> [Me]
>> As explained by Nico, having the boot loader decompress the
>> kernel is *bad*.
>
> This is your point of view, but others (including me) think different.
Yes, as C. B. Roylance Kent stated in 1893:
Those are my principles, but if y
Dear Linus Walleij,
In message
you wrote:
>
> > Can I assume that we have (or can have) a 'make uImage' target or
> > similar in the kernel which can pack together:
> >
> > - a compressed kernel (not zImage, I mean something that U-Boot can
> > decompress), with a rel_offset of 32KB
>
> As exp
On Tue, Nov 8, 2011 at 2:10 AM, Simon Glass wrote:
> Can I assume that we have (or can have) a 'make uImage' target or
> similar in the kernel which can pack together:
>
> - a compressed kernel (not zImage, I mean something that U-Boot can
> decompress), with a rel_offset of 32KB
As explained by
Dear Stephen Warren,
In message <4eb9acdf.90...@nvidia.com> you wrote:
>
> > What would happen if we just create a new image type IH_TYPE_ZIMAGE?
>
> That would cover the kernel uImage case. We'd also need a new image type
> for "use in place" FDTs, since that also gets relocated to the image
> l
On 11/08/2011 02:17 PM, Wolfgang Denk wrote:
> Dear Stephen,
>
> In message <2008194433.7c9a013be...@gemini.denx.de> I wrote:
>>
>>> Are you willing to entertain extending bootm to recognize a third image
>>> format if this makes the patches less invasive, and/or leads to more
>>> maintainable
Dear Stephen,
In message <2008194433.7c9a013be...@gemini.denx.de> I wrote:
>
> > Are you willing to entertain extending bootm to recognize a third image
> > format if this makes the patches less invasive, and/or leads to more
> > maintainable code?
>
> I have to admit that I don't like the i
On Tue, 8 Nov 2011, Jason wrote:
> It sounds like you are intending for distributions to provide uImages.
> Why can't they provide a generic zImage, and a post-install hook runs
> mkimage to add the board specific uImage header? Similar to update-grub
> on x86{_64}. This seems _more_ flexible to
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> Dear Nicolas Pitre,
>
> In message you wrote:
> >
> > > In both cases the _kernel_ image is not position independent. It must
> > > be loaded to a specific address and started at a specific entry point.
> > > The exact information where these are is kn
Dear Stephen Warren,
In message <74cdbe0f657a3d45afbb94109fb122ff173f9a5...@hqmail01.nvidia.com> you
wrote:
>
> > bootm is for uImage format. I see no sense in "extending" it.
>
> bootm already supports two completely different formats; legacy uImage
> and FIT images. To me, it seems logical to
(resending due to MIME encoding last time; sorry)
On 11/08/2011 04:50 AM, Wolfgang Denk wrote:
> Dear Marek Vasut,
>
> In message <20081235.05464.marek.va...@gmail.com> you wrote:
>>
>> Ok, so guys ... let me ask a stupid question:
>
> Not a stupid question at all.
>
>> Will it be a problem
Hello Wolfgang and Nicolas,
please allow me to barge in at that point.
As I strongly believe that we all want to advance our software in a
technical sense and not spend time in flame wars - I am trying to think
of ways forward from the current state of affairs.
Without evaluating all the argumen
Dear Nicolas Pitre,
In message you wrote:
>
> > In both cases the _kernel_ image is not position independent. It must
> > be loaded to a specific address and started at a specific entry point.
> > The exact information where these are is known at built time, and
> > somehow encoded in the images
> On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> > In message you wrote:
> > > > I understand you are referring here to zImages only. Correct?
> > >
> > > Correct. Anything else is not relocatable.
> > >
> > > > Or will raw images (without the preloader) be fully relocatable, too?
> > >
> > > No.
Nicolas,
On Mon, Nov 07, 2011 at 10:51:33PM -0500, Nicolas Pitre wrote:
> On Mon, 7 Nov 2011, Simon Glass wrote:
>
> > On Mon, Nov 7, 2011 at 4:35 PM, Nicolas Pitre wrote:
> >
> > > On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> > >
> > >> Dear Nicolas Pitre,
> > >>
> > >> > We don't want any hardc
On Mon, Nov 07, 2011, Simon Glass wrote:
> How can we give U-Boot what it
> wants, which is apparently the ability to decompress the kernel itself
> and arrange everything in memory at the right place? Wolfgang
> complains that patches to do this have been repea
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> In message you wrote:
> >
> > > I understand you are referring here to zImages only. Correct?
> >
> > Correct. Anything else is not relocatable.
> >
> > > Or will raw images (without the preloader) be fully relocatable, too?
> >
> > No.
>
> OK. So t
> Dear Marek Vasut,
>
> In message <20081235.05464.marek.va...@gmail.com> you wrote:
> > Ok, so guys ... let me ask a stupid question:
> Not a stupid question at all.
>
> > Will it be a problem to extend bootm (if not already done) to load
> > zImages directly, with -z option for example ? Wo
Dear Marek Vasut,
In message <20081235.05464.marek.va...@gmail.com> you wrote:
>
> Ok, so guys ... let me ask a stupid question:
Not a stupid question at all.
> Will it be a problem to extend bootm (if not already done) to load zImages
> directly, with -z option for example ? Won't that sat
> Dear Nicolas Pitre,
>
> In message you wrote:
> > > But as you said yourself, the (raw) kernel is not relocatable. It
> > > gets loaded and started at pre-defined (at image build time)
> > > addresses. Only the kernel wrapper adds the complexity you are
> > > complaining about. Drop it, then
Dear Simon Glass,
In message
you wrote:
>
> > Firstly, there is not just u-Boot out there. And since the layout
> > optimization for Linux when decompressing is by definition Linux
> > specific, this better live in zImage than be duplicated in every
> > bootloaders.
>
> Actually I was talking
Dear Nicolas Pitre,
In message you wrote:
>
> > But as you said yourself, the (raw) kernel is not relocatable. It
> > gets loaded and started at pre-defined (at image build time)
> > addresses. Only the kernel wrapper adds the complexity you are
> > complaining about. Drop it, then.
>
> Many
Dear Nicolas,
may I suggest that you please try to relax for a moment, and try to
look at things from a completely unprejudiced point of view? We will
come back to your arguments later, promised.
In message you wrote:
>
> > I understand you are referring here to zImages only. Correct?
>
> Cor
Hi Nicolas,
On Mon, Nov 7, 2011 at 7:51 PM, Nicolas Pitre wrote:
> On Mon, 7 Nov 2011, Simon Glass wrote:
>
>> On Mon, Nov 7, 2011 at 4:35 PM, Nicolas Pitre wrote:
>>
>> > On Tue, 8 Nov 2011, Wolfgang Denk wrote:
>> >
>> >> Dear Nicolas Pitre,
>> >>
>> >> > We don't want any hardcoded architectu
On Mon, 7 Nov 2011, Simon Glass wrote:
> On Mon, Nov 7, 2011 at 4:35 PM, Nicolas Pitre wrote:
>
> > On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> >
> >> Dear Nicolas Pitre,
> >>
> >> > We don't want any hardcoded architecture specific address anymore.
> >> > This is being removed from the kernel as
Hi Nicolas,
On Mon, Nov 7, 2011 at 4:35 PM, Nicolas Pitre wrote:
> On Tue, 8 Nov 2011, Wolfgang Denk wrote:
>
>> Dear Nicolas Pitre,
>>
>> In message you wrote:
>> >
>> > > 1) zImages are are relocatable. They should be loaded and started at
>> > > offsets between 32 KiB and 128 MiB in system
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <4eb87375.1040...@nvidia.com> you wrote:
> >
> > The only place that has full knowledge of the board's memory layout is
> > the U-Boot environment for that board, and hence I assert that the
> > U-Boot environment shou
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
> Dear Nicolas Pitre,
>
> In message you wrote:
> >
> > > 1) zImages are are relocatable. They should be loaded and started at
> > >offsets between 32 KiB and 128 MiB in system RAM.
> > >
> > > 2) Raw images (without the preloader) have to be started
Dear Stephen Warren,
In message <4eb87375.1040...@nvidia.com> you wrote:
>
> The only place that has full knowledge of the board's memory layout is
> the U-Boot environment for that board, and hence I assert that the
> U-Boot environment should define where to load the kernel (and initrd
> and FDT
Dear Stephen Warren,
In message <4eb87122.3050...@nvidia.com> you wrote:
>
> The uncompressed image needs to end up at 32K-from-start-of-SDRAM (or
> whatever SoC-specific value the kernel defines). If U-Boot puts the
> zImage at that same location, the first thing the U-Boot decompressor
> must do
On 11/07/2011 04:25 PM, Wolfgang Denk wrote:
> Dear Nicolas Pitre,
>
> In message you wrote:
>>
>>> 1) zImages are are relocatable. They should be loaded and started at
>>>offsets between 32 KiB and 128 MiB in system RAM.
>>>
>>> 2) Raw images (without the preloader) have to be started at a f
On 11/07/2011 04:08 PM, Wolfgang Denk wrote:
> In message <4eb85bf3.8030...@nvidia.com> you [Stephen Warren] wrote:
...
>> The fundamental problem with uImage having an absolute load address is
>> that there may be no single absolute address that is usable as SDRAM
>> across all ARM SoCs which may
On 11/07/2011 04:10 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <4eb85ea6.3000...@nvidia.com> you wrote:
>>
>>> and we have to add additional configuration information to the boot
>>> loader.
>>
>> Sorry, I'm unclear what "additional configuration information" needs to
>> be add
Dear Nicolas Pitre,
In message you wrote:
>
> > 1) zImages are are relocatable. They should be loaded and started at
> >offsets between 32 KiB and 128 MiB in system RAM.
> >
> > 2) Raw images (without the preloader) have to be started at a fixed
> >address, virt_to_phys(PAGE_OFFSET + TEX
Dear Stephen Warren,
In message <4eb85ea6.3000...@nvidia.com> you wrote:
>
> > and we have to add additional configuration information to the boot
> > loader.
>
> Sorry, I'm unclear what "additional configuration information" needs to
> be added to the boot-loader, and which of cases (1) and (2)
Dear Stephen Warren,
In message <4eb85bf3.8030...@nvidia.com> you wrote:
>
> I think the difference here is that I get the impression that people
> within the U-Boot community would like to do away with zImage in general
> and replace it with uImage, which simply isn't plausible, whereas I'm
> per
On Mon, 7 Nov 2011, Wolfgang Denk wrote:
> Dear Marek Vasut,
>
> In message <20072204.41980.marek.va...@gmail.com> you wrote:
> >
> > You have that runtime patching stuff in linux-arm-kernel now, there should
> > be no
> > problem with that anymore actually. So basically I understood there
Dear Nicolas,
In message you wrote:
>
> So yes, this is a simplistic solution, but it is damn good, and it
> solves the u-Boot restrictions we've been complaining about for at least
> two years now.
Could you please explain which of these restrictions cannot be solved
by using the IH_TYPE_*_R
On Mon, 7 Nov 2011, Stephen Warren wrote:
> (Sigh, resending again to avoid rejected MIME encoding)
>
> On 11/07/2011 01:26 PM, Wolfgang Denk wrote:
> > Dear Stephen Warren,
> >
> > In message <74cdbe0f657a3d45afbb94109fb122ff173f9a5...@hqmail01.nvidia.com>
> > you wrote:
> >> Anyway, I have wi
On 11/07/2011 03:27 PM, Wolfgang Denk wrote:
> Dear Marek Vasut,
>
> In message <20072204.41980.marek.va...@gmail.com> you wrote:
>>
>> You have that runtime patching stuff in linux-arm-kernel now, there should
>> be no
>> problem with that anymore actually. So basically I understood there w
On 11/07/2011 03:11 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <74cdbe0f657a3d45afbb94109fb122ff173f9a5...@hqmail01.nvidia.com>
> you wrote:
>>
>> "Stuck with" isn't really a good description.
>
> It is, IMO.
>
>> zImage is a way of booting ARM Linux. There may be others(?),
Dear Marek Vasut,
In message <20072204.41980.marek.va...@gmail.com> you wrote:
>
> You have that runtime patching stuff in linux-arm-kernel now, there should be
> no
> problem with that anymore actually. So basically I understood there was an
> agreement to make special uImage/fitImage whic
Dear Stephen Warren,
In message <74cdbe0f657a3d45afbb94109fb122ff173f9a5...@hqmail01.nvidia.com> you
wrote:
>
> "Stuck with" isn't really a good description.
It is, IMO.
> zImage is a way of booting ARM Linux. There may be others(?), but zImage
> is certainly a valid and popular mechanism. I do
On 11/07/2011 02:59 PM, Marek Vasut wrote:
>> On 11/07/2011 02:04 PM, Marek Vasut wrote:
>> ...
>>
The problem with this new approach is that Linux kernel images are NOT
freely relocatable. They do have a fix entry point, even if this is
not an absolute address, but a relative one.
> On 11/07/2011 02:04 PM, Marek Vasut wrote:
> ...
>
> >> The problem with this new approach is that Linux kernel images are NOT
> >> freely relocatable. They do have a fix entry point, even if this is
> >> not an absolute address, but a relative one. The natural way to
> >> handle this is exact
On 11/07/2011 02:04 PM, Marek Vasut wrote:
...
>> The problem with this new approach is that Linux kernel images are NOT
>> freely relocatable. They do have a fix entry point, even if this is
>> not an absolute address, but a relative one. The natural way to
>> handle this is exactly that: add s
(Sigh, resending again to avoid rejected MIME encoding)
On 11/07/2011 01:26 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <74cdbe0f657a3d45afbb94109fb122ff173f9a5...@hqmail01.nvidia.com>
> you wrote:
>>
>>> Your own IH_TYPE_*_REL patches are queued and will be merged soon.
>>
>>
Simon Glass wrote at Monday, November 07, 2011 12:47 PM:
> On Mon, Nov 7, 2011 at 9:09 AM, Stephen Warren wrote:
> > On 11/07/2011 09:56 AM, Stephen Warren wrote:
> >> [Resending in an attempt to avoid base64 encoding]
> >>
> >> On 11/05/2011 04:20 PM, Wolfgang Denk wrote:
> >>> Dear Stephen Warre
> Dear Stephen Warren,
>
> In message <74cdbe0f657a3d45afbb94109fb122ff173f9a5...@hqmail01.nvidia.com>
you wrote:
> > > Your own IH_TYPE_*_REL patches are queued and will be merged soon.
> >
> > Oh. I kept pushing and pushing on these and kept meeting resistance. I
>
> There was no resistance e
Dear Simon Glass,
In message
you wrote:
>
> > copy it." Given the way Linux zImage works, I know
> > this works fine on all those SoCs, and even if it didn't, the U-Boot
> > scripts for those SoCs could arrange for the uImage to be loaded to a
> > SoC-specific address that the zImage /would/ wo
Dear Stephen Warren,
In message <74cdbe0f657a3d45afbb94109fb122ff173f9a5...@hqmail01.nvidia.com> you
wrote:
>
> > Your own IH_TYPE_*_REL patches are queued and will be merged soon.
>
> Oh. I kept pushing and pushing on these and kept meeting resistance. I
There was no resistance ever. There we
Hi Stephen,
On Mon, Nov 7, 2011 at 9:09 AM, Stephen Warren wrote:
> On 11/07/2011 09:56 AM, Stephen Warren wrote:
>> [Resending in an attempt to avoid base64 encoding]
>>
>> On 11/05/2011 04:20 PM, Wolfgang Denk wrote:
>>> Dear Stephen Warren,
>>>
>>> In message <1320164902-24190-3-git-send-email
On 11/07/2011 09:56 AM, Stephen Warren wrote:
> [Resending in an attempt to avoid base64 encoding]
>
> On 11/05/2011 04:20 PM, Wolfgang Denk wrote:
>> Dear Stephen Warren,
>>
>> In message <1320164902-24190-3-git-send-email-swar...@nvidia.com> you wrote:
>>> The legacy uImage format includes an ab
[Resending in an attempt to avoid base64 encoding]
On 11/05/2011 04:20 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
>
> In message <1320164902-24190-3-git-send-email-swar...@nvidia.com> you wrote:
>> The legacy uImage format includes an absolute load and entry-
>> point address. When presented
Dear Stephen Warren,
In message <1320164902-24190-3-git-send-email-swar...@nvidia.com> you wrote:
> The legacy uImage format includes an absolute load and entry-
> point address. When presented with a uImage in memory that
> isn't loaded at the address in the image's load address,
> U-Boot will re
The legacy uImage format includes an absolute load and entry-
point address. When presented with a uImage in memory that
isn't loaded at the address in the image's load address,
U-Boot will relocate the image to its address in the header.
Some payloads can actually be loaded and used at any arbitr
56 matches
Mail list logo
