[Top][All Lists]
[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