U-boot Archive mirror
 help / color / mirror / Atom feed

From: "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To: "Heinrich Schuchardt" <xypron.glpk@gmx.de>
Cc: "Tom Rini" <trini@konsulko.com>, "Simon Glass" <sjg@chromium.org>,
	u-boot@lists.denx.de
Subject: Re: [PATCH RFC] doc: Document address spaces used by U-Boot
Date: Sat, 18 May 2024 12:35:55 +0100	[thread overview]
Message-ID: <1d7b798a-5f1e-4b69-84b4-044456fe8a89@app.fastmail.com> (raw)
In-Reply-To: <a4d513ec-2f6e-464b-8167-462e05615571@gmx.de>



在2024年5月18日五月 上午9:08，Heinrich Schuchardt写道：
> On 5/17/24 13:45, Jiaxun Yang wrote:
[...]

Hi Heinrich,

Ah sorry I should really spell check it before sending it off....
It was copied directly from my personal note.

> %s/optinos/options/
>
> Relating to gd->bd->bi_dram[] or LMB just adds a layer of confusion to
> the reader. I would not refer to specific internal structures in this
> document.

So it's a developer oriented document and I decided to add some examples.

>
>> +used as arguments to load commands. It is recommended to use ``sysmem_addr_t``
>> +to store ``sysmem`` address.
>
> In most places long is used.
>
>> +
>> +It is further used by sandbox to simulate memory, and by MIPS to handle
>> +differences between ``virt`` and ``phys`` address spaces.
>
> You have been submitting patches to implement EFI for MIPS.
>
> The EFI specification explicitly requires a 1:1 mapping in the MMU
> between. virtual and physical addresses.
>
> In what respect does MIPS not comply to this?
>
> In how far do MIPS addresses shown in the CLI differ from the physical
> addresses (i.e. addresses on the electrical address lines)?

So for MIPS we need to apply a fixed offset to physical address to get a
usable virtual address, i.e. 0x1000 physical is 0x80001000 virtual. That
mapping is guaranteed by the hardware, and you can't disable it even after
enabling MMU.

All CLIs are currently using virtual address.

For EFI all table address passed are virtual-ish address.

>
> CONFIG_ARCH_MAP_SYSMEM seems only to be set on the sandbox and not on
> MIPS. We should try to keep it that way.
>

I'm actually trying to introduce ARCH_MAP_SYSMEM abstraction to MIPS
because currently it's totally a mess about virtual vs physical everywhere.

I think eventually we should convert most internal data structure (and cmd
arguments) to use physical address for consistency, but converting all
existing boards to that model cost an arm and a leg. So my plan is to introduce
an option telling if sysmem is virtual or physical and let boards opt-in
that option.

Thanks

>
> To summarize. If I have not mistaken anything about MIPS:
>
> All physical devices are identity mapped.
>
> The sandbox uses a virtual address space incorrectly called 'physical'
> which is mapped to the virtual address space of the host. This sandbox
> virtual address space is used in
>
> * the command line interface
> * in the sandbox device-tree
> * in environment variable
>
> This allows using the same address values in sandbox tests irrespective
> of what part of the host RAM was mapped via mmap().
>
> Best regards
>
> Heinrich
>
[...]
-- 
- Jiaxun

     prev parent reply	other threads:[~2024-05-18 11:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-17 11:45 [PATCH RFC] doc: Document address spaces used by U-Boot Jiaxun Yang
2024-05-18  8:08 ` Heinrich Schuchardt
2024-05-18 11:35   ` Jiaxun Yang [this message]

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=1d7b798a-5f1e-4b69-84b4-044456fe8a89@app.fastmail.com \
    --to=jiaxun.yang@flygoat.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /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

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 read-only IMAP folder(s) and NNTP newsgroup(s).