On Wed, Apr 23, 2014 at 12:47 PM, lig.f...@cn.fujitsu.com <lig.f...@cn.fujitsu.com> wrote: >> -----邮件原件----- >> 发件人: qemu-devel-bounces+lig.fnst=cn.fujitsu....@nongnu.org >> [mailto:qemu-devel-bounces+lig.fnst=cn.fujitsu....@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 >> <c...@codeaurora.org> wrote: >> > On 04/17/2014 06:02 AM, Peter Maydell wrote: >> >> On 2 April 2014 13:47, Peter Maydell <peter.mayd...@linaro.org> wrote: >> >>> On 2 April 2014 13:11, Peter Crosthwaite <peter.crosthwa...@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. >> > >
