qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH 08/14] aspeed: Replace direct get_system_memory() calls


From: Peter Delevoryas
Subject: Re: [PATCH 08/14] aspeed: Replace direct get_system_memory() calls
Date: Thu, 23 Jun 2022 18:45:30 +0000


> On Jun 23, 2022, at 8:39 AM, Cédric Le Goater <clg@kaod.org> wrote:
> 
> On 6/23/22 14:57, Peter Maydell wrote:
>> On Thu, 23 Jun 2022 at 13:37, Peter Delevoryas <pdel@fb.com> wrote:
>>> 
>>> Note: sysbus_mmio_map(), sysbus_mmio_map_overlap(), and others are still
>>> using get_system_memory indirectly.
>>> 
>>> Signed-off-by: Peter Delevoryas <pdel@fb.com>
>>> ---
>>>  hw/arm/aspeed.c         | 8 ++++----
>>>  hw/arm/aspeed_ast10x0.c | 5 ++---
>>>  hw/arm/aspeed_ast2600.c | 2 +-
>>>  hw/arm/aspeed_soc.c     | 6 +++---
>>>  4 files changed, 10 insertions(+), 11 deletions(-)
>>> 
>>> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
>>> index 8dae155183..3aa74e88fb 100644
>>> --- a/hw/arm/aspeed.c
>>> +++ b/hw/arm/aspeed.c
>>> @@ -371,7 +371,7 @@ static void aspeed_machine_init(MachineState *machine)
>>>                           amc->uart_default);
>>>      qdev_realize(DEVICE(&bmc->soc), NULL, &error_abort);
>>> 
>>> -    memory_region_add_subregion(get_system_memory(),
>>> +    memory_region_add_subregion(bmc->soc.system_memory,
>>>                                  sc->memmap[ASPEED_DEV_SDRAM],
>>>                                  &bmc->ram_container);
>> This is board code, it shouldn't be reaching into the internals
>> of the SoC object like this. The board code probably already
>> has the right MemoryRegion because it was the one that passed
>> it to the SoC link porperty in the first place.
> 
> It's a bit messy currently. May be I got it wrong initially. The
> board allocates a ram container region in which the machine ram
> region is mapped. See commit ad1a9782186d ("aspeed: add a RAM memory
> region container")
> 
> There is an extra region after ram in the ram container to catch
> invalid access done by FW. That's how FW determines the size of
> ram. See commit ebe31c0a8ef7 ("aspeed: add a max_ram_size property
> to the memory controller")
> 
> But I think I can safely move all the RAM logic under the board.
> I will send a patch.

Ah yes, I noticed that this was odd too, and that the DRAM probably
should have been mapped inside the SoC code. I didn’t know exactly
how to solve it easily though. Thanks for sending a patch Cedric!!

> 
> Thanks,
> 
> C.
> 
>> thanks
>> -- PMM
> 


reply via email to

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