qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Kumar Gala <kumar.gala@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	qemu-arm <qemu-arm@nongnu.org>,
	Kevin Townsend <kevin.townsend@linaro.org>
Subject: Re: [PATCH 0/3] mps3-an524: support memory remapping
Date: Tue, 13 Apr 2021 18:33:32 +0200	[thread overview]
Message-ID: <6c6bca82-ba03-62dc-0c74-2efc85fa160e@amsat.org> (raw)
In-Reply-To: <fab25109-f8c9-f8e2-4d56-ba76c5c79341@amsat.org>

On 4/13/21 6:29 PM, Philippe Mathieu-Daudé wrote:> On 4/12/21 4:48 PM,
Peter Maydell wrote:
>> On Mon, 12 Apr 2021 at 15:37, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>> On 4/12/21 3:43 PM, Peter Maydell wrote:
>>>> The AN524 FPGA image supports two memory maps, which differ
>>>> in where the QSPI and BRAM are. In the default map, the BRAM
>>>> is at 0x0000_0000, and the QSPI at 0x2800_0000. In the second
>>>> map, they are the other way around.
>>>>
>>>> In hardware, the initial mapping can be selected by the user
>>>> by writing either "REMAP: BRAM" (the default) or "REMAP: QSPI"
>>>> in the board configuration file. The guest can also dynamically
>>>> change the mapping via the SCC CFG_REG0 register.
>>>>
>>>> This patchset adds support for the feature to QEMU's model;
>>>> the user-sets-the-initial-mapping part is a new machine property
>>>> which can be set with "-M remap=QSPI".
>>>>
>>>> This is needed for some guest images -- for instance the
>>>> Arm TF-M binaries -- which assume they have the QSPI layout.
>>>
>>> I tend to see machine property set on the command line similar
>>> to hardware wire jumpers, externally set (by an operator having
>>> access to the hardware, not guest code).
>>>
>>> Here the remap behavior you described is triggered by the guest.
>>> Usually this is done by a bootloader code before running the
>>> guest code.
>>> Couldn't we have the same result using a booloader (like -bios
>>> cmd line option) rather than modifying internal peripheral state?
>>
> 
> (
> 
>> In the real hardware, the handling of the board configuration
>> file is done by the "Motherboard Configuration Controller", which
>> is an entirely separate microcontroller on the dev board but outside
>> the FPGA, and which is responsible for things like loading image
>> files off the SD card and writing them to memory, setting a bunch
>> of initial configuration including the remap setting but also
>> things like setting the oscillators to the values that this
>> particular FPGA image needs. It's also what makes the board
>> appear to a connected computer as a USB mass storage device so
>> you can update the SD card files via USB cable rather than doing
>> lots of plugging and unplugging, and it is what loads the FPGA
>> image off SD card and into the FPGA in the first place.
> 
> ) [*]
> 
>> QEMU is never going to implement the MCC as a real emulated
>> guest CPU; instead our models hard-code some of the things it
>> does. I think that a machine property (a thing set externally
>> to the guest CPU and valid before any guest CPU code executes)
>> is a reasonable way to implement the remap setting, which from
>> the point of view of the CPU inside the FPGA is a thing set
>> externally and valid before any guest CPU code executes.
> 
> OK now I understand the picture, the MCC is external. In that case
> the machine property is a clean way to address that.
> 
> Could you add the first paragraph of your answer ([*]) in patch 3
> description (before the current comment) to make it clearer?

(In case you agree, no need to respin).


  reply	other threads:[~2021-04-13 16:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-12 13:43 [PATCH 0/3] mps3-an524: support memory remapping Peter Maydell
2021-04-12 13:43 ` [PATCH 1/3] hw/misc/mps2-scc: Add "QEMU interface" comment Peter Maydell
2021-04-12 13:43 ` [PATCH 2/3] hw/misc/mps2-scc: Support using CFG0 bit 0 for remapping Peter Maydell
2021-04-13 16:30   ` Philippe Mathieu-Daudé
2021-04-12 13:43 ` [PATCH 3/3] hw/arm/mps2-tz: Implement AN524 memory remapping via machine property Peter Maydell
2021-04-13 16:51   ` Philippe Mathieu-Daudé
2021-04-12 14:37 ` [PATCH 0/3] mps3-an524: support memory remapping Philippe Mathieu-Daudé
2021-04-12 14:48   ` Peter Maydell
2021-04-13 16:29     ` Philippe Mathieu-Daudé
2021-04-13 16:33       ` Philippe Mathieu-Daudé [this message]
2021-04-12 18:39 ` Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6c6bca82-ba03-62dc-0c74-2efc85fa160e@amsat.org \
    --to=f4bug@amsat.org \
    --cc=kevin.townsend@linaro.org \
    --cc=kumar.gala@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).