QEMU: ARM: boot: Load kernel at an Image friendly address

PATCH New Joel Fernandes 8 participants 20 messages Mar 25, 2014 – Apr 28, 2014

Share & tools

Joel Fernandes

author

2014-03-25 03:34 UTC #0 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

Loading kernel at offset 0x10000 works only for zImage, but not for Image, because the kernel expect the start of decompressed kernel (.head.text) to be at an address that's a distance that's 16MB aligned from PAGE_OFFSET + TEXT_OFFSET (see vmlinux.lds.S). This check is enfornced in __fixup_pv_table in arch/arm/kernel/head.S TEXT_OFFSET is 0x00008000, so a 16MB alignment needs to have a "0x8000" in the lower 16 bits so that they cancel out. Currently the offset Qemu loads it at is 0x10000.

With zImage, this need is met because zImage loads the uncompressed Image correctly, however when loading an Image and executing directly Qemu is required it to load it at the correct location. Doing so, doesn't break Qemu's zImage loading. With this patch, both zImage and Image work correctly.

Signed-off-by Joel Fernandes <[email protected]>

---
 hw/arm/boot.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

hw/arm/boot.c +1 -1

index dc62918..566b5c2 100644
@@ -23,7 +23,7 @@
  * They have different preferred image load offsets from system RAM base.
  */
 #define KERNEL_ARGS_ADDR 0x100
-#define KERNEL_LOAD_ADDR 0x00010000
+#define KERNEL_LOAD_ADDR 0x00008000
 #define KERNEL64_LOAD_ADDR 0x00080000
 
 typedef enum {

Signature · 1 line

1.7.9.5

Christopher Covington

2014-03-25 12:29 UTC #1 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

Hi Joel,

Quoted 2 lines · Joel Fernandes

Loading kernel at offset 0x10000 works only for zImage, but not for Image, because the kernel expect the start of decompressed kernel (.head.text) to be

Nit: expects

Quoted 2 lines

at an address that's a distance that's 16MB aligned from PAGE_OFFSET + TEXT_OFFSET (see vmlinux.lds.S). This check is enfornced in __fixup_pv_table in

Nit: enforced

Quoted 8 lines

arch/arm/kernel/head.S TEXT_OFFSET is 0x00008000, so a 16MB alignment needs to have a "0x8000" in the lower 16 bits so that they cancel out. Currently the offset Qemu loads it at is 0x10000.
With zImage, this need is met because zImage loads the uncompressed Image correctly, however when loading an Image and executing directly Qemu is required it to load it at the correct location. Doing so, doesn't break Qemu's zImage loading. With this patch, both zImage and Image work correctly.

I had just been playing with my own version of this change. Glad to see it going upstream.

Tested-by Christopher Covington <[email protected]>

Thanks,
Christopher

Signature · 3 lines

Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

Joel Fernandes

2014-03-25 13:43 UTC #2 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

Quoted 22 lines · Christopher Covington

Hi Joel,
Quoted 2 lines · Joel Fernandes
Loading kernel at offset 0x10000 works only for zImage, but not for Image, because the kernel expect the start of decompressed kernel (.head.text) to be
Nit: expects
Quoted 2 lines
at an address that's a distance that's 16MB aligned from PAGE_OFFSET + TEXT_OFFSET (see vmlinux.lds.S). This check is enfornced in __fixup_pv_table in
Nit: enforced
Quoted 8 lines
arch/arm/kernel/head.S TEXT_OFFSET is 0x00008000, so a 16MB alignment needs to have a "0x8000" in the lower 16 bits so that they cancel out. Currently the offset Qemu loads it at is 0x10000.
With zImage, this need is met because zImage loads the uncompressed Image correctly, however when loading an Image and executing directly Qemu is required it to load it at the correct location. Doing so, doesn't break Qemu's zImage loading. With this patch, both zImage and Image work correctly.

Quoted 5 lines

I had just been playing with my own version of this change. Glad to see it going upstream.
Tested-by Christopher Covington <[email protected]>

Thanks, I updated the patch with these changes.

-Joel

Peter Maydell

2014-03-25 13:13 UTC #3 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

In reply to Joel Fernandes

Quoted 23 lines · Joel Fernandes

Loading kernel at offset 0x10000 works only for zImage, but not for Image, because the kernel expect the start of decompressed kernel (.head.text) to be at an address that's a distance that's 16MB aligned from PAGE_OFFSET + TEXT_OFFSET (see vmlinux.lds.S). This check is enfornced in __fixup_pv_table in arch/arm/kernel/head.S TEXT_OFFSET is 0x00008000, so a 16MB alignment needs to have a "0x8000" in the lower 16 bits so that they cancel out. Currently the offset Qemu loads it at is 0x10000.
With zImage, this need is met because zImage loads the uncompressed Image correctly, however when loading an Image and executing directly Qemu is required it to load it at the correct location. Doing so, doesn't break Qemu's zImage loading. With this patch, both zImage and Image work correctly.
Signed-off-by Joel Fernandes <[email protected]>
---
 hw/arm/boot.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
hw/arm/boot.c +0 -0
index dc62918..566b5c2 100644

hw/arm/boot.c line 27

Quoted 6 lines

hw/arm/boot.c +1 -1

@@ -23,7 +23,7 @@
  * They have different preferred image load offsets from system RAM base.
  */
 #define KERNEL_ARGS_ADDR 0x100
-#define KERNEL_LOAD_ADDR 0x00010000
+#define KERNEL_LOAD_ADDR 0x00008000
 #define KERNEL64_LOAD_ADDR 0x00080000

The patch and rationale seem plausible, but I'm a bit reluctant to apply this this close to 2.0 release, because QEMU has loaded images at this address for 8 years without anybody complaining, and I worry that we might accidentally break some other use case somehow.

thanks
-- PMM

Joel Fernandes

author

2014-03-25 13:46 UTC #4 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

Quoted 28 lines · Peter Maydell

Quoted 27 lines · Joel Fernandes
Loading kernel at offset 0x10000 works only for zImage, but not for Image, because the kernel expect the start of decompressed kernel (.head.text) to be at an address that's a distance that's 16MB aligned from PAGE_OFFSET + TEXT_OFFSET (see vmlinux.lds.S). This check is enfornced in __fixup_pv_table in arch/arm/kernel/head.S TEXT_OFFSET is 0x00008000, so a 16MB alignment needs to have a "0x8000" in the lower 16 bits so that they cancel out. Currently the offset Qemu loads it at is 0x10000.
With zImage, this need is met because zImage loads the uncompressed Image correctly, however when loading an Image and executing directly Qemu is required it to load it at the correct location. Doing so, doesn't break Qemu's zImage loading. With this patch, both zImage and Image work correctly.
Signed-off-by Joel Fernandes <[email protected]>
---
 hw/arm/boot.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
hw/arm/boot.c +0 -1
index dc62918..566b5c2 100644
@@ -23,7 +23,7 @@
  * They have different preferred image load offsets from system RAM base.
  */
 #define KERNEL_ARGS_ADDR 0x100
-#define KERNEL_LOAD_ADDR 0x00010000

Quoted 8 lines

hw/arm/boot.c line 27
Quoted 2 lines
hw/arm/boot.c +1 -0
+#define KERNEL_LOAD_ADDR 0x00008000
 #define KERNEL64_LOAD_ADDR 0x00080000
The patch and rationale seem plausible, but I'm a bit reluctant to apply this this close to 2.0 release, because QEMU has loaded images at this address for 8 years without anybody complaining, and I worry that we might accidentally break some other use case somehow.

I understand.
FWIW, I also tested with a15-vexpress and zImage.

thanks,

-Joel

Peter Maydell

2014-04-01 17:10 UTC #5 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

In reply to Joel Fernandes

Quoted 8 lines · Joel Fernandes

Loading kernel at offset 0x10000 works only for zImage, but not for Image, because the kernel expect the start of decompressed kernel (.head.text) to be at an address that's a distance that's 16MB aligned from PAGE_OFFSET + TEXT_OFFSET (see vmlinux.lds.S). This check is enfornced in __fixup_pv_table in arch/arm/kernel/head.S TEXT_OFFSET is 0x00008000, so a 16MB alignment needs to have a "0x8000" in the lower 16 bits so that they cancel out. Currently the offset Qemu loads it at is 0x10000.

Quoted 6 lines

With zImage, this need is met because zImage loads the uncompressed Image correctly, however when loading an Image and executing directly Qemu is required it to load it at the correct location. Doing so, doesn't break Qemu's zImage loading. With this patch, both zImage and Image work correctly.
Signed-off-by Joel Fernandes <[email protected]>

Reviewed-by Peter Maydell <[email protected]>

I'll put this in target-arm.next after 2.0 has released.

thanks
-- PMM

Peter Crosthwaite

2014-04-02 12:11 UTC #6 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

Quoted 9 lines · Peter Maydell

Quoted 8 lines · Joel Fernandes
Loading kernel at offset 0x10000 works only for zImage, but not for Image, because the kernel expect the start of decompressed kernel (.head.text) to be at an address that's a distance that's 16MB aligned from PAGE_OFFSET + TEXT_OFFSET (see vmlinux.lds.S). This check is enfornced in __fixup_pv_table in arch/arm/kernel/head.S TEXT_OFFSET is 0x00008000, so a 16MB alignment needs to have a "0x8000" in the lower 16 bits so that they cancel out. Currently the offset Qemu loads it at is 0x10000.

Quoted 9 lines

Quoted 6 lines
With zImage, this need is met because zImage loads the uncompressed Image correctly, however when loading an Image and executing directly Qemu is required it to load it at the correct location. Doing so, doesn't break Qemu's zImage loading. With this patch, both zImage and Image work correctly.
Signed-off-by Joel Fernandes <[email protected]>
Reviewed-by Peter Maydell <[email protected]>

Like others, I have been carrying this change locally. Good to see it up!

Reviewed-by Peter Crosthwaite <[email protected]>

Tested-by Peter Crosthwaite <[email protected]>

Quoted 5 lines

I'll put this in target-arm.next after 2.0 has released.
thanks
-- PMM

Peter Maydell

2014-04-02 12:47 UTC #7 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

Quoted 1 line · Peter Crosthwaite

Like others, I have been carrying this change locally. Good to see it up!

Why are you all booting raw Images anyway (just out of curiosity)? All my test cases boot either a zImage or a uImage, or occasionally a full SD card image, or I'd have noticed this earlier...

thanks
-- PMM

Peter Crosthwaite

2014-04-02 12:58 UTC #8 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

Quoted 7 lines · Peter Maydell

Quoted 1 line · Peter Crosthwaite
Like others, I have been carrying this change locally. Good to see it up!
Why are you all booting raw Images anyway (just out of curiosity)? All my test cases boot either a zImage or a uImage, or occasionally a full SD card image, or I'd have noticed this earlier...

Simplicity more than anything. It is much easier to debug against head.S (esp. with the -d in_asm option), when you can see the head.s asm as the very first thing the CPU executes. Otherwise you gotta filter out the zImage stuffs. There have also been occasions where I have broken QEMU locally as part of some random work-in-progress development such that the zImage head doesnt work and i'd rather just move my debug efforts to kernel proper. None of them are fantastic reasons from a user perspective but it's just a little easier on developing.

Regards,
Peter

Quoted 3 lines

thanks
-- PMM

Christopher Covington

2014-04-02 15:04 UTC #9 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

In reply to Peter Maydell

Quoted 6 lines · Peter Maydell

Quoted 1 line · Peter Crosthwaite
Like others, I have been carrying this change locally. Good to see it up!
Why are you all booting raw Images anyway (just out of curiosity)? All my test cases boot either a zImage or a uImage, or occasionally a full SD card image, or I'd have noticed this earlier...

I do it in part for uniformity with arm64 kernels.

Christopher

Signature · 3 lines

Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

Joel Fernandes

2014-04-02 16:06 UTC #10 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

In reply to Peter Maydell

Quoted 6 lines · Peter Maydell

Quoted 1 line · Peter Crosthwaite
Like others, I have been carrying this change locally. Good to see it up!
Why are you all booting raw Images anyway (just out of curiosity)? All my test cases boot either a zImage or a uImage, or occasionally a full SD card image, or I'd have noticed this earlier...

zImage fails for me on OMAP1, which I'm debugging, the errors have more to do with writing out of memory limits. But I was not sure if the problem was with decompression or something else, so I wanted to boot the basic case (Image) first.

Thanks,
-Joel

Peter Maydell

2014-04-17 10:02 UTC #11 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

In reply to Peter Maydell

Quoted 4 lines · Peter Maydell

Quoted 1 line · Peter Crosthwaite
Like others, I have been carrying this change locally. Good to see it up!
Why are you all booting raw Images anyway (just out of curiosity)?

Given the recent feedback from the kernel mailing list (viz "don't boot Image unless you really know what you're doing, the correct load image may change randomly depending what other board support is in a multikernel image, etc") maybe we should just remove the Image booting support instead? Clearly nobody who hasn't locally patched QEMU is using it at the moment...

thanks
-- PMM

Christopher Covington

2014-04-17 13:34 UTC #12 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

Quoted 4 lines · Peter Maydell

Quoted 3 lines · Peter Maydell
Quoted 1 line · Peter Crosthwaite
Like others, I have been carrying this change locally. Good to see it up!

Quoted 8 lines

Quoted 1 line
Why are you all booting raw Images anyway (just out of curiosity)?
Given the recent feedback from the kernel mailing list (viz "don't boot Image unless you really know what you're doing, the correct load image may change randomly depending what other board support is in a multikernel image, etc") maybe we should just remove the Image booting support instead? Clearly nobody who hasn't locally patched QEMU is using it at the moment...

An opportunity for a fresh start at low-level loading facilities, should anyone be inclined to pursue it, sounds good to me.

Christopher

Signature · 3 lines

Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

Joel Fernandes

2014-04-17 16:53 UTC #13 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

Quoted 14 lines · Christopher Covington

Quoted 4 lines · Peter Maydell
Quoted 3 lines · Peter Maydell
Quoted 1 line · Peter Crosthwaite
Like others, I have been carrying this change locally. Good to see it up!
Quoted 8 lines
Quoted 1 line
Why are you all booting raw Images anyway (just out of curiosity)?
Given the recent feedback from the kernel mailing list (viz "don't boot Image unless you really know what you're doing, the correct load image may change randomly depending what other board support is in a multikernel image, etc") maybe we should just remove the Image booting support instead? Clearly nobody who hasn't locally patched QEMU is using it at the moment...

Quoted 6 lines

An opportunity for a fresh start at low-level loading facilities, should anyone be inclined to pursue it, sounds good to me.
Christopher
--

I'm still wondering here, multi-arch may break, but we can put a disclaimer in the Qemu code stating so that Image loading is not recommended and risky. Clearly that's better than just deleting raw Image loading functionality from Qemu boot loader altogether?

We can load the Image at any good address to make sure maximum number of TEXT_OFFSETs are happy. I found this exercise in part making __fixup_pv_table happy. Again I'm *not* advocating a hack, but I'm a bit against the idea of just removing the code.

Nicholas idea is great to store TEXT_OFFSET in the start of stext and parse it from bootloader but we wouldn't want to mainline those kernel changes for just those few users, makes sense.

Peter, were you saying instead that we deprecate Image loading and switch to uImage for those folks requiring uncompressed loading in Qemu? IIRC uImage just wraps zImage so doesn't help folks not requiring compression, but no reason why mkimage can't be made to do that- just that the kernel doesn't do it by default (Correct me if I'm wrong).

I'm not a big fan of raw image loading for that matter ;-) I only did it because at one point, compressed image loading was breaking with OMAP1 on Qemu and uncompressed Image loading was breaking because of offset.

thanks,
-Joel

Peter Crosthwaite

2014-04-23 02:20 UTC #14 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

In reply to Christopher Covington

Quoted 14 lines · Christopher Covington

Quoted 4 lines · Peter Maydell
Quoted 3 lines · Peter Maydell
Quoted 1 line · Peter Crosthwaite
Like others, I have been carrying this change locally. Good to see it up!
Quoted 8 lines
Quoted 1 line
Why are you all booting raw Images anyway (just out of curiosity)?
Given the recent feedback from the kernel mailing list (viz "don't boot Image unless you really know what you're doing, the correct load image may change randomly depending what other board support is in a multikernel image, etc") maybe we should just remove the Image booting support instead? Clearly nobody who hasn't locally patched QEMU is using it at the moment...

Quoted 3 lines

An opportunity for a fresh start at low-level loading facilities, should anyone be inclined to pursue it, sounds good to me.

FWIW, im already using my own bootloader out of tree that cuts in on this lower level. I'm getting close to be able to throw away -kernel and friends completely. To implement I have it as a QOMified device so you just add it on the command line:

qemu-system-foo -device loader,image=/path/to/file[,addr=0xdeadbeef][,cpunr=X]

To load a particular image to a particular CPU (and it is repeatable).

You can:

1: Load elfs and uImages (addr= is ignored)
2: Load raw or zImages
3: Load data files at arbitrary addresses (cpunr= is ignored)

With this, you can BYO secondary bootloops or even run multiple guests of different CPUs. You can also boot on a non-zeroth CPU. You can place raw images wherever you want (the issue in this thread). You can also load in firmware to ROMs.

I then have a tiny hack to make -kernel optional for all ARM. Bootloader works for at least ARM and Microblaze, haven't tested for others yet.

Regards,
Peter

Quoted 7 lines

Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation.

lig.fnst at cn.fujitsu.com

2014-04-23 02:47 UTC #15 lore raw

Quoted 27 lines

-----????-----
???: qemu-devel-bounces+lig.fnst=cn.fujitsu.com at nongnu.org [mailto:qemu-devel-bounces+lig.fnst=cn.fujitsu.com at nongnu.org] ?? Peter Crosthwaite
????: 2014?4?23? 10:20
???: Christopher Covington
??: Joel Fernandes; Peter Maydell; QEMU Developers; Linux ARM Kernel List ??: Re: [Qemu-devel] [PATCH] QEMU: ARM: boot: Load kernel at an Image friendly address
Quoted 3 lines · Christopher Covington
Quoted 2 lines · Peter Maydell
Quoted 1 line · Peter Maydell
On 2 April 2014 13:11, Peter Crosthwaite <[email protected]>
Quoted 11 lines · wrote:
Quoted 10 lines
Quoted 3 lines
Quoted 1 line
Like others, I have been carrying this change locally. Good to see it up!
Why are you all booting raw Images anyway (just out of curiosity)?
Given the recent feedback from the kernel mailing list (viz "don't boot Image unless you really know what you're doing, the correct load image may change randomly depending what other board support is in a multikernel image, etc") maybe we should just remove the Image booting support instead? Clearly nobody who hasn't locally patched QEMU is using it at the moment...

Quoted 7 lines

Quoted 3 lines
An opportunity for a fresh start at low-level loading facilities, should anyone be inclined to pursue it, sounds good to me.
FWIW, im already using my own bootloader out of tree that cuts in on this lower level. I'm getting close to be able to throw away -kernel and friends completely.

Me too :-)

To implement I have it as a QOMified device so you just add it on

Quoted 5 lines

the command line:
qemu-system-foo -device loader,image=/path/to/file[,addr=0xdeadbeef][,cpunr=X]
To load a particular image to a particular CPU (and it is repeatable).

Why in to a particular CPU?
The motivation is ?

Thanks!

Quoted 26 lines

You can:
1: Load elfs and uImages (addr= is ignored)
2: Load raw or zImages
3: Load data files at arbitrary addresses (cpunr= is ignored)
With this, you can BYO secondary bootloops or even run multiple guests of different CPUs. You can also boot on a non-zeroth CPU. You can place raw images wherever you want (the issue in this thread). You can also load in firmware to ROMs.
I then have a tiny hack to make -kernel optional for all ARM. Bootloader works for at least ARM and Microblaze, haven't tested for others yet.
Regards,
Peter
Quoted 7 lines
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation.

Rob Herring

2014-04-17 16:58 UTC #16 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

In reply to Peter Maydell

Quoted 4 lines · Peter Maydell

Quoted 3 lines · Peter Maydell
Quoted 1 line · Peter Crosthwaite
Like others, I have been carrying this change locally. Good to see it up!

Quoted 8 lines

Quoted 1 line
Why are you all booting raw Images anyway (just out of curiosity)?
Given the recent feedback from the kernel mailing list (viz "don't boot Image unless you really know what you're doing, the correct load image may change randomly depending what other board support is in a multikernel image, etc") maybe we should just remove the Image booting support instead? Clearly nobody who hasn't locally patched QEMU is using it at the moment...

Including AArch64, too? :) It happens to be correct ATM, but really we should be looking the Image header to determine the offset. I heard Mark Rutland has some patches to do TEXT_OFFSET randomization in fact.

The choice of 0x10000 is not really a good one either as this forces the decompressor to move itself out of the way first. I guess it is a good choice if your goal is to test the worst possible code path for the decompressor.

Rob

Peter Maydell

2014-04-17 19:26 UTC #17 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

Quoted 14 lines · Rob Herring

Quoted 4 lines · Peter Maydell
Quoted 3 lines · Peter Maydell
Quoted 1 line · Peter Crosthwaite
Like others, I have been carrying this change locally. Good to see it up!
Quoted 8 lines
Quoted 1 line
Why are you all booting raw Images anyway (just out of curiosity)?
Given the recent feedback from the kernel mailing list (viz "don't boot Image unless you really know what you're doing, the correct load image may change randomly depending what other board support is in a multikernel image, etc") maybe we should just remove the Image booting support instead? Clearly nobody who hasn't locally patched QEMU is using it at the moment...

Quoted 3 lines

Including AArch64, too? :) It happens to be correct ATM, but really we should be looking the Image header to determine the offset. I heard Mark Rutland has some patches to do TEXT_OFFSET randomization in fact.

AArch64 is different -- the Image format is sanely specified and includes enough information to get it right. (The fact that we don't currently do so is a clear QEMU bug.)

Quoted 4 lines

The choice of 0x10000 is not really a good one either as this forces the decompressor to move itself out of the way first. I guess it is a good choice if your goal is to test the worst possible code path for the decompressor.

The major awkwardness with AArch32 zImage is that it doesn't give you enough information to know how big the zImage will be uncompressed, so it's not possible for the bootloader to sanity check that all the various bits and pieces aren't going to overlap (and the kernel doesn't check either IIRC, so if things go wrong they go wrong in various obscure ways).

We could certainly rearrange where QEMU puts things; the current setup results from a mixture of:
* legacy "this is how we've always done it" (and the fact that if we get things wrong and the uncompressed kernel overlaps with the DTB or initrd then the failure is unhelpfully cryptic has generally been a pressure towards "don't tweak things too much")
* handling both Image and zImage (and now AArch64 Image) in broadly similar codepaths
* wanting to handle both boards with what by modern standards are tiny amounts of memory and also boards with gigabytes of RAM, even though optimal choices for location are going to differ

I don't insist that we drop AArch32 Image support (or necessarily even think we should gratuitously do so), but if it makes it simpler to refactor the code to better handle the other options then I don't particularly object to that happening. I do think that it seems like an AArch32 Image loader that would be useful to end-users ought to provide them with some way to specify the load address or offset.

thanks
-- PMM

Peter Crosthwaite

2014-04-23 02:07 UTC #18 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

Quoted 47 lines · Peter Maydell

Quoted 14 lines · Rob Herring
Quoted 4 lines · Peter Maydell
Quoted 3 lines · Peter Maydell
Quoted 1 line · Peter Crosthwaite
Like others, I have been carrying this change locally. Good to see it up!
Quoted 8 lines
Quoted 1 line
Why are you all booting raw Images anyway (just out of curiosity)?
Given the recent feedback from the kernel mailing list (viz "don't boot Image unless you really know what you're doing, the correct load image may change randomly depending what other board support is in a multikernel image, etc") maybe we should just remove the Image booting support instead? Clearly nobody who hasn't locally patched QEMU is using it at the moment...
Quoted 3 lines
Including AArch64, too? :) It happens to be correct ATM, but really we should be looking the Image header to determine the offset. I heard Mark Rutland has some patches to do TEXT_OFFSET randomization in fact.
AArch64 is different -- the Image format is sanely specified and includes enough information to get it right. (The fact that we don't currently do so is a clear QEMU bug.)
Quoted 4 lines
The choice of 0x10000 is not really a good one either as this forces the decompressor to move itself out of the way first. I guess it is a good choice if your goal is to test the worst possible code path for the decompressor.
The major awkwardness with AArch32 zImage is that it doesn't give you enough information to know how big the zImage will be uncompressed, so it's not possible for the bootloader to sanity check that all the various bits and pieces aren't going to overlap (and the kernel doesn't check either IIRC, so if things go wrong they go wrong in various obscure ways).
We could certainly rearrange where QEMU puts things; the current setup results from a mixture of:
* legacy "this is how we've always done it" (and the fact that if we get things wrong and the uncompressed kernel overlaps with the DTB or initrd then the failure is unhelpfully cryptic has generally been a pressure towards "don't tweak things too much")
* handling both Image and zImage (and now AArch64 Image) in broadly similar codepaths
* wanting to handle both boards with what by modern standards are tiny amounts of memory and also boards with gigabytes of RAM, even though optimal choices for location are going to differ

Quoted 8 lines

I don't insist that we drop AArch32 Image support (or necessarily even think we should gratuitously do so), but if it makes it simpler to refactor the code to better handle the other options then I don't particularly object to that happening. I do think that it seems like an AArch32 Image loader that would be useful to end-users ought to provide them with some way to specify the load address or offset.

Regarding implementation of new bootloader specific user properties - the issue was discussed in my attempt to QOMify the ARM bootloader:

http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00962.html

Now that the dust has settled on QOM (I believe that QOM instability was a dis-encouraging factor at that time). Perhaps we should revist that QOMification idea and punch all these magic numbers through as (over-ridable) props? -global and friends does the rest without ARM specific intrusion on machine and boot opts (vl.c etc).

Regards,
Peter

Quoted 3 lines

thanks
-- PMM

Uwe Kleine-König

2014-04-28 16:19 UTC #19 lore raw

PATCH 1/1 QEMU: ARM: boot: Load kernel at an Image friendly address

In reply to Joel Fernandes

Quoted 7 lines · Joel Fernandes

Loading kernel at offset 0x10000 works only for zImage, but not for Image, because the kernel expect the start of decompressed kernel (.head.text) to be at an address that's a distance that's 16MB aligned from PAGE_OFFSET + TEXT_OFFSET (see vmlinux.lds.S). This check is enfornced in __fixup_pv_table in arch/arm/kernel/head.S TEXT_OFFSET is 0x00008000, so a 16MB alignment needs to have a "0x8000" in the lower 16 bits so that they cancel out. Currently the offset Qemu loads it at is 0x10000.

I'm not a native speaker, but I think the wording and logic is broken. I think what you mean is:

An uncompressed ARM kernel Image must be loaded to the (physical) address PHYS_OFFSET + TEXT_OFFSET. (If CONFIG_ARM_PATCH_PHYS_VIRT=y the condition is more lax, but we cannot assume this to be enabled.)

Speaking about PAGE_OFFSET doesn't make sense here, because that's a virual address and the MMU is expected to be off (or loaded with a 1:1 mapping). Also note that not all machines use TEXT_OFFSET == 0x8000, see

git grep textofs- arch/arm/Makefile

Additionally let me note, that for a zImage most addresses should work, but there are more and less sensible ones. Both PHYS_OFFSET + 0x8000 and PHYS_OFFSET + 0x10000 are in the latter group. That's because the compressed image and the then uncompressed image overlap, so you loose booting time by relocating one of them. Not sure if you care.

As you cannot determine the actual value of TEXT_OFFSET for a given Image, I'd recommend to only support booting zImages and then place it somewhere at the end of RAM.

Best regards
Uwe

Signature · 2 lines

Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |