qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] hw/arm_boot.c: bump initrd address (again) to a


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH] hw/arm_boot.c: bump initrd address (again) to accommodate large kernels
Date: Mon, 8 Oct 2012 10:09:53 +1000

On Mon, Oct 8, 2012 at 8:36 AM, Peter Maydell <address@hidden> wrote:
> On 7 October 2012 23:27, Cole Robinson <address@hidden> wrote:
>> From: Paul Whalen <address@hidden>
>>
>> Fedora ARM is generating kernels that exceed the hardcoded size limits:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=862766
>>
>> Bump the load address, as was previously done in 756ba3b
>>
>> Signed-off-by: Cole Robinson <address@hidden>
>> ---
>>  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 a6e9143..3cabb71 100644
>> --- a/hw/arm_boot.c
>> +++ b/hw/arm_boot.c
>> @@ -18,7 +18,7 @@
>>
>>  #define KERNEL_ARGS_ADDR 0x100
>>  #define KERNEL_LOAD_ADDR 0x00010000
>> -#define INITRD_LOAD_ADDR 0x00d00000
>> +#define INITRD_LOAD_ADDR 0x01d00000
>
> This makes me sad but I still have no idea what we could
> do that would be better than this...
>

Way back when I tried to QOMify the arm bootloader, initrd location
was a device option for the boot-loader device:

qemu-system-arm -M foo -device arm-bootloader,initrdaddr=0xdeadbeef

Give it a sane default, and those who have a problem can then override
it. When the bootloader detects the collision between the image and
initrd blobs, a nice error message suggest a command line arg to
rearrange the locations for initrd, dtb and friends.

A comment In general, there are so many inflexibilites in the arm
bootloader and you have stated a long term goal of unifying the
bootloaders accross architectures. But so far the fixes for problems
like this are always blocked by the desire for backwards
compatilbilty. To that end, perhaps we can leave the arm bootloader as
is, deparacte it, then fork bootloader development with a highly
configurable multi-platform QOM bootloader that does have accessible
controls for properties like this?

Another completely different but workable solution is to dynamically
determine a initrd (and dtb) location. Any reason why the bootloader
can't track what memory real estate is in use by what pieces and just
pick a piece of vacant real estate big enough for the dtb or initrd?
Its hard if elfs are invloved, but for raw images it should be
trivial.

Regards,
Peter

> -- PMM
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]