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:
On Tue, Nov 8, 2011 at 2:10 AM, Simon Glass s...@chromium.org 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
Dear Linus Walleij,
In message cacrpkdy7fov87fuss+kfbdtyghr2ntbtxzveedrbuawxehp...@mail.gmail.com
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
On Sat, Dec 10, 2011 at 11:53 PM, Wolfgang Denk w...@denx.de 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,
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 alpine.lfd.2.02.071840080.3...@xanadu.home you wrote:
I understand you are
Dear Nicolas Pitre,
In message alpine.lfd.2.02.071942150.3...@xanadu.home 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
Dear Simon Glass,
In message CAPnjgZ2aRP5Hn-3jREa=ofgs0k7ny9b2mwp3pwpbrw5svl3...@mail.gmail.com
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
Dear Nicolas Pitre,
In message alpine.lfd.2.02.071942150.3...@xanadu.home 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
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
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
In message alpine.lfd.2.02.071840080.3...@xanadu.home 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,
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
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 n...@fluxnic.net wrote:
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
Dear Nicolas Pitre,
We don't want any hardcoded
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
In message alpine.lfd.2.02.071840080.3...@xanadu.home 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
Dear Nicolas Pitre,
In message alpine.lfd.2.02.080847540.3...@xanadu.home 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
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
(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 to extend
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 simply
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
Dear Nicolas Pitre,
In message alpine.lfd.2.02.080847540.3...@xanadu.home 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
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
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 idea, but I
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 code?
I have
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
load
[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 with a
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 absolute load
Hi Stephen,
On Mon, Nov 7, 2011 at 9:09 AM, Stephen Warren swar...@nvidia.com 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
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 were
Dear Simon Glass,
In message CAPnjgZ1vb9DB=ukrs0tg47zryubc0svg5vk0whuvn3b7_5u...@mail.gmail.com
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
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
Simon Glass wrote at Monday, November 07, 2011 12:47 PM:
On Mon, Nov 7, 2011 at 9:09 AM, Stephen Warren swar...@nvidia.com 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
(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.
Oh. I kept
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 support
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
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. The natural way
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 don't see
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 which ...
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(?), but zImage
is
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 was an
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 withdrawn my
Dear Nicolas,
In message alpine.lfd.2.02.07160.3...@xanadu.home 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
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 was an
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
perfectly
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) that
Dear Nicolas Pitre,
In message alpine.lfd.2.02.071736280.3...@xanadu.home 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
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 added to the
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 be
On 11/07/2011 04:25 PM, Wolfgang Denk wrote:
Dear Nicolas Pitre,
In message alpine.lfd.2.02.071736280.3...@xanadu.home 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
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 is
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), and
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
Dear Nicolas Pitre,
In message alpine.lfd.2.02.071736280.3...@xanadu.home 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
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 should define
Hi Nicolas,
On Mon, Nov 7, 2011 at 4:35 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
Dear Nicolas Pitre,
In message alpine.lfd.2.02.071736280.3...@xanadu.home you wrote:
1) zImages are are relocatable. They should be loaded and started at
On Mon, 7 Nov 2011, Simon Glass wrote:
On Mon, Nov 7, 2011 at 4:35 PM, Nicolas Pitre n...@fluxnic.net 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 we
Hi Nicolas,
On Mon, Nov 7, 2011 at 7:51 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Mon, 7 Nov 2011, Simon Glass wrote:
On Mon, Nov 7, 2011 at 4:35 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
Dear Nicolas Pitre,
We don't want any hardcoded
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
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
55 matches
Mail list logo
