qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [qemuppc] virtex_ml507: Add support for loading kernel uI


From: Alexander Graf
Subject: Re: [Qemu-ppc] [qemuppc] virtex_ml507: Add support for loading kernel uImage binary.
Date: Fri, 8 Jun 2012 14:31:57 +0200

On 08.06.2012, at 14:28, Elvis Dowson wrote:

> Hi Alex,
> 
> On Jun 8, 2012, at 2:13 PM, Alexander Graf wrote:
> 
>>>   memory_region_init_ram(phys_ram, "ram", ram_size);
>>>   vmstate_register_ram_global(phys_ram);
>>> -    memory_region_add_subregion(address_space_mem, ram_base, phys_ram);
>>> +    memory_region_add_subregion(address_space_mem, loadaddr, phys_ram);
>> 
>> What does the ram offset have to do with the uimage load base?
>> 
>>> 
>>> +        /* Boot a kernel uImage binary. */
>>> +        kernel_size = load_uimage(kernel_filename, &entry, &loadaddr, 
>>> NULL);
>>> +
>> 
>> In the uImage case we don't have to set bootstrap_pc? :)
> 
> Is there some document somewhere on setting the bootstrap_pc? 

IIUC it's just the starting IP after reset.

> Adding the above changes allowed me to load the uImage, and qemu-system-ppc 
> boots partially and gets stuck with the message VFS: Cannot open root device 
> "hda" 
> or unknown-block(2,0), as stated in an email I sent across to the list 
> earlier.

That's orthogonal though. Maybe the emulation doesn't expose an IDE adapter? :)

> So, if I can learn a bit more about the boot process in QEMU, it would be 
> great.

Well, usually what happens is that the "loader" (uImage, elf, ...) gives you an 
entry point address. You then take that entry point and pass it to whatever 
wants to jump into the kernel - usually the reset handler on simple boards.

So in the above case, you just want to move the bootstrap_pc = line out of the 
elf conditional branch, because it applies just the same for uImage. In both 
cases, you pass in &entry.


Alex




reply via email to

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