On 10/2/18 6:12 PM, Peter Maydell wrote:
> On 2 October 2018 at 16:48, Cédric Le Goater wrote:
>> On 10/2/18 12:56 PM, Peter Maydell wrote:
>>> Rather than having the DMA device directly grab the system_memory
>>> MR like this, it's better to have the device have a MemoryRegion
>>> property, which
On 2 October 2018 at 16:48, Cédric Le Goater wrote:
> On 10/2/18 12:56 PM, Peter Maydell wrote:
>> Rather than having the DMA device directly grab the system_memory
>> MR like this, it's better to have the device have a MemoryRegion
>> property, which the SoC sets with whatever the DMA device shou
With the links,
[ ... ]
>> Otherwise, patch looks good, though I don't know enough about
>> the device/SoC to review those details.
>
> For the moment the only use of these registers is in the Aspeed custom
> u-boot of the SDK :
https://github.com/openbmc/u-boot/blob/v2016.07-aspeed-openbmc/a
On 10/2/18 12:56 PM, Peter Maydell wrote:
> On 21 September 2018 at 17:19, Cédric Le Goater wrote:
>> The FMC controller on the Aspeed SoCs support DMA to access the flash
>> modules. It can operate in a normal mode, to copy to or from the flash
>> module mapping window, or in a checksum calculati
On 21 September 2018 at 17:19, Cédric Le Goater wrote:
> The FMC controller on the Aspeed SoCs support DMA to access the flash
> modules. It can operate in a normal mode, to copy to or from the flash
> module mapping window, or in a checksum calculation mode, to evaluate
> the best clock settings
The FMC controller on the Aspeed SoCs support DMA to access the flash
modules. It can operate in a normal mode, to copy to or from the flash
module mapping window, or in a checksum calculation mode, to evaluate
the best clock settings for reads.
The model introduces a custom address space for DMAs
