qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 1/2] arm_boot: Assume Linux boot flow when -d


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v2 1/2] arm_boot: Assume Linux boot flow when -dtb given
Date: Fri, 22 Jun 2012 23:27:08 +1000

Ping!

Any thoughts Peter?

Regards,
Peter

On Wed, Jun 20, 2012 at 11:45 AM, Peter Crosthwaite
<address@hidden> wrote:
> It matches my flow in the real hardware.
>
> Heres the scenario where we need this (FYI applies to both microblaze and 
> arm):
>
> User creates a Linux elf that includes a built in dtb. Slave mode
> bootloader boots the real hardware with the elf (my actual real JTAG
> bootloader work with elfs).
>
> However QEMU doesn't support all the hardware devices the kernel
> supports, so we need the QEMU linux bootloader to override the built
> in DTB (with -dtb) to stop the kernel probing non-existent devices.
> So, if the user specifies a dtb, adopt the linux bootloader flow
> instead, before jumping to the elf entry point. r2 get set to the -dtb
> argument and it boots with the modified dtb.
>
> Make sense?
>
> It all comes down to I need a bootloader functionality (mainly dtb but
> SMP stuff would be nice too) before booting my elf.
>
> Every time i touch this arm bootloader we end up in a discussion about
> how it needs to be rewritten cos of flawed assumptions etc (like elfs
> are not Linux). Can we just accept this and throw it out with the
> trash when someone refactors the arm bootloader properly?
>
> Regards,
> Peter
>
> On Tue, Jun 19, 2012 at 11:06 PM, Peter Maydell
> <address@hidden> wrote:
>> On 18 June 2012 02:35, Peter A. G. Crosthwaite
>> <address@hidden> wrote:
>>> If the user boots with a -dtb assume the Linux boot flow, even when 
>>> handling an
>>> elf.
>>
>> We don't do this for -initrd, why should we do it for -dtb ?
>
> Maybe we should do it for initrd too. If the user specifies either of
> these options they are trying to boot Linux.
>
>>
>> -- PMM



reply via email to

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