| Message ID | 1395718484-20424-1-git-send-email-joelf@ti.com |
|---|---|
| State | New |
| Headers | show |
Hi Joel, On 03/24/2014 11:34 PM, Joel Fernandes wrote: > 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 > 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 > 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 <cov@codeaurora.org> Thanks, Christopher
On 25 March 2014 03:34, Joel Fernandes <joelf@ti.com> wrote: > 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 <joelf@ti.com> > --- > hw/arm/boot.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/arm/boot.c b/hw/arm/boot.c > index dc62918..566b5c2 100644 > --- a/hw/arm/boot.c > +++ b/hw/arm/boot.c > @@ -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
On Tue, Mar 25, 2014 at 7:29 AM, Christopher Covington <cov@codeaurora.org> wrote: > Hi Joel, > > On 03/24/2014 11:34 PM, Joel Fernandes wrote: >> 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 > >> 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 > >> 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 <cov@codeaurora.org> > Thanks, I updated the patch with these changes. -Joel
On 03/25/2014 08:13 AM, Peter Maydell wrote: > On 25 March 2014 03:34, Joel Fernandes <joelf@ti.com> wrote: >> 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 <joelf@ti.com> >> --- >> hw/arm/boot.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/hw/arm/boot.c b/hw/arm/boot.c >> index dc62918..566b5c2 100644 >> --- a/hw/arm/boot.c >> +++ b/hw/arm/boot.c >> @@ -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. I understand. FWIW, I also tested with a15-vexpress and zImage. thanks, -Joel
On 25 March 2014 03:34, Joel Fernandes <joelf@ti.com> wrote: > 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 <joelf@ti.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> I'll put this in target-arm.next after 2.0 has released. thanks -- PMM
On Wed, Apr 2, 2014 at 3:10 AM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 25 March 2014 03:34, Joel Fernandes <joelf@ti.com> wrote: >> 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 <joelf@ti.com> > > Reviewed-by: Peter Maydell <peter.maydell@linaro.org> > Like others, I have been carrying this change locally. Good to see it up! Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Tested-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com> > I'll put this in target-arm.next after 2.0 has released. > > thanks > -- PMM >
On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote:
> 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
On Wed, Apr 2, 2014 at 10:47 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >> 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 > thanks > -- PMM >
[On 04/02/2014 08:47 AM, Peter Maydell wrote: > On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >> 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
On Wed, Apr 2, 2014 at 7:47 AM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >> 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
On 2 April 2014 13:47, Peter Maydell <peter.maydell@linaro.org> wrote: > On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >> 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
On 04/17/2014 06:02 AM, Peter Maydell wrote: > On 2 April 2014 13:47, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >>> 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... An opportunity for a fresh start at low-level loading facilities, should anyone be inclined to pursue it, sounds good to me. Christopher
On Thu, Apr 17, 2014 at 8:34 AM, Christopher Covington <cov@codeaurora.org> wrote: > On 04/17/2014 06:02 AM, Peter Maydell wrote: >> On 2 April 2014 13:47, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >>>> 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... > > 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
On Thu, Apr 17, 2014 at 5:02 AM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 2 April 2014 13:47, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >>> 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... 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
On 17 April 2014 17:58, Rob Herring <robherring2@gmail.com> wrote: > On Thu, Apr 17, 2014 at 5:02 AM, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 2 April 2014 13:47, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >>>> 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... > > 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.) > 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
On Fri, Apr 18, 2014 at 5:26 AM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 17 April 2014 17:58, Rob Herring <robherring2@gmail.com> wrote: >> On Thu, Apr 17, 2014 at 5:02 AM, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 2 April 2014 13:47, Peter Maydell <peter.maydell@linaro.org> wrote: >>>> On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >>>>> 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... >> >> 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.) > >> 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. > 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 > thanks > -- PMM >
On Thu, Apr 17, 2014 at 11:34 PM, Christopher Covington <cov@codeaurora.org> wrote: > On 04/17/2014 06:02 AM, Peter Maydell wrote: >> On 2 April 2014 13:47, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> wrote: >>>> 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... > > 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 > Christopher > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by the Linux Foundation. >
> -----邮件原件----- > 发件人: qemu-devel-bounces+lig.fnst=cn.fujitsu.com@nongnu.org > [mailto:qemu-devel-bounces+lig.fnst=cn.fujitsu.com@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 > > On Thu, Apr 17, 2014 at 11:34 PM, Christopher Covington > <cov@codeaurora.org> wrote: > > On 04/17/2014 06:02 AM, Peter Maydell wrote: > >> On 2 April 2014 13:47, Peter Maydell <peter.maydell@linaro.org> wrote: > >>> On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> > wrote: > >>>> 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... > > > > 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 > 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! > > 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 > > > Christopher > > > > -- > > Employee of Qualcomm Innovation Center, Inc. > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > > hosted by the Linux Foundation. > >
On Wed, Apr 23, 2014 at 12:47 PM, lig.fnst@cn.fujitsu.com <lig.fnst@cn.fujitsu.com> wrote: >> -----邮件原件----- >> 发件人: qemu-devel-bounces+lig.fnst=cn.fujitsu.com@nongnu.org >> [mailto:qemu-devel-bounces+lig.fnst=cn.fujitsu.com@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 >> >> On Thu, Apr 17, 2014 at 11:34 PM, Christopher Covington >> <cov@codeaurora.org> wrote: >> > On 04/17/2014 06:02 AM, Peter Maydell wrote: >> >> On 2 April 2014 13:47, Peter Maydell <peter.maydell@linaro.org> wrote: >> >>> On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwaite@xilinx.com> >> wrote: >> >>>> 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... >> > >> > 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 >> 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 ? Multiple different guests on different CPUs. BTW, I used your blob loader as the starting point of development, so I have merely extended it with these image and cpu features. Regards, Peter > > Thanks! > >> >> 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 >> >> > Christopher >> > >> > -- >> > Employee of Qualcomm Innovation Center, Inc. >> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >> > hosted by the Linux Foundation. >> > >
On Mon, Mar 24, 2014 at 10:34:44PM -0500, Joel Fernandes wrote: > 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
diff --git a/hw/arm/boot.c b/hw/arm/boot.c index dc62918..566b5c2 100644 --- a/hw/arm/boot.c +++ b/hw/arm/boot.c @@ -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 {
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 <joelf@ti.com> --- hw/arm/boot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)