qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2] aspeed/smc: add a 'sdram_base' property


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 1/2] aspeed/smc: add a 'sdram_base' property
Date: Mon, 20 Feb 2017 14:38:27 +0000

On 20 February 2017 at 14:30, Cédric Le Goater <address@hidden> wrote:
> On 02/20/2017 02:51 PM, Peter Maydell wrote:
>> On 13 February 2017 at 14:44, Cédric Le Goater <address@hidden> wrote:
>>> The setting of the DRAM address of the DMA transaction depends on the
>>> DRAM base address of the SoC. Let's add a property to give this
>>> information to the SMC controller model.
>>>
>>> Signed-off-by: Cédric Le Goater <address@hidden>
>>> Reviewed-by: Joel Stanley <address@hidden>
>>> Reviewed-by: Andrew Jeffery <address@hidden>
>>> --
>>
>> This seems a bit weird -- what does it actually do in hardware?
>> (Does it really have the ability to dma anywhere in the
>> address space and just use an odd base address, or is it
>> DMA'ing to a more restricted address space?)
>
> For the AST2500, the valid address range for the DRAM side start
> address of the DMA is [ 0x80000000 - 0xBFFFFFFF ] which is the
> full 1024M SDRAM space. It will wrap back in case of overflow.
>
> For the AST2400, it is [ 0x40000000 - 0x5FFFFFFF ] which is the
> full 512M SDRAM space.
>
> And the length of the DMA goes from 4 bytes to 32MB [ O - 0x7FFFFF ]

So if I do a DMA access to 0x800000 that's the same as an
access at 0x0, or does it fail?

I ask because the other option for modelling this kind of thing
would be that you make the DMA controller device take a link
property which is a MemoryRegion*. Then inside the DMA device
you create the AddressSpace* which you use to do DMA accesses,
and in the board code you pass the DMA device a suitably
constructed MemoryRegion that contains the things that the
device can DMA to.

You don't have to do it that way (and I don't think we
have much in the way of examples of doing it like that,
except for the ARM CPU handling of secure and nonsecure
memory address spaces), but if it seems to fit better
with what the hardware's doing it might be worth the effort.

thanks
-- PMM



reply via email to

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