qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 4/7] m25p80: add a m25p80_set_rom_storage() rout


From: Cédric Le Goater
Subject: Re: [Qemu-devel] [PATCH 4/7] m25p80: add a m25p80_set_rom_storage() routine
Date: Sat, 24 Sep 2016 10:25:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

On 09/23/2016 08:26 PM, mar.krzeminski wrote:
> Hi Cedric,
> 
> W dniu 23.09.2016 o 10:28, Cédric Le Goater pisze:
>> On 09/23/2016 10:17 AM, Peter Maydell wrote:
>>> On 23 September 2016 at 08:19, Cédric Le Goater <address@hidden> wrote:
>>>> But the goal is to boot from the device, so I added a memory region alias
>>>> at 0 to trigger the flash module mmios at boot time, as this is where
>>>> u-boot expects to be.
>>>>
>>>> and I fell in this trap :/
>>>>
>>>>          aspeed_smc_flash_read: To 0x0 of size 1: 0xbe mode:0
>>>>          Bad ram pointer (nil)
>>>>          Aborted (core dumped)
>>>>
>>>> There is a failure in get_page_addr_code(), possibly because qemu uses
>>>> byte per byte reads of the code (cpu_ldub_code). But this is beyond my
>>>> understanding of qemu's internal.
>>> This is a bug in how we report the problem, but the underlying
>>> issue here is attempting to execute from something that's not RAM
>>> or ROM. You can't execute code out of something backed by MMIO.
>> OK. So I see two solutions. T
>>
>> The "brutal" one which is to copy the flash contents in a rom blob
>> at 0, but there is still an issue in getting access to the storage
>> anyhow, as it is internal to m25p80. Or we should get the name of the
>> backing file of the drive but I am not sure we are expected to do
>> that as I don't see any API for it.
>>
>> The other solution is something like this patch which lets the storage
>> of the flash device be assigned externally.
> Since I do not like dirty hacks in the code, I want just to suggest a 
> workaround, that probably you will not like ;]

It's a feature ! :) 

I am just trying to find a solution to this issue. So, we could also 
introduce a routine :

+uint8_t *m25p80_get_storage(DeviceState *dev, uint32_t *size)
+{
+    Flash *s = M25P80(dev);
+
+    *size = s->size;
+    return s->storage;
+}

and use rom_add_blob_fixed() with the return values. Maybe this is less 
intrusive in the m25p80 device model flow. Thoughts ? 

> As Qemu expects that first running code will be in ROM or RAM memory,
> you can implement in your board -bios option that you will use to
> pass u-boot binary to rom memory, or even use generic loader functionality
> when it reach master.

but if we use -bios <file> to have a ROM, we will need to pass a second 
time <file> as a drive to have a CS0 flash slave: 

        -bios "flash-palmetto-test"  \
        -drive file="flash-palmetto-test",format=raw,if=mtd \
        -drive file="palmetto.pnor",format=raw,if=mtd

This feels awkward. The virt platform and vexpress forbid that for 
instance.

Are there any other platform with similar need ? 

Thanks,
C. 



reply via email to

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