public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] inappropriate PCI configuration on arm64 qemu?
Date: Fri, 1 Jun 2018 16:21:23 +0900	[thread overview]
Message-ID: <20180601072121.GO30789@linaro.org> (raw)
In-Reply-To: <90911aa7-0d5e-70aa-a1e0-5f0ee94195a3@iki.fi>

Tuomas,

On Thu, May 31, 2018 at 01:32:20PM +0300, Tuomas Tynkkynen wrote:
> Hi Akashi,
> 
> On 05/31/2018 08:05 AM, AKASHI Takahiro wrote:
> >Simon,
> >
> >On Wed, May 30, 2018 at 01:18:30PM -0600, Simon Glass wrote:
> >>+Tuomas
> >>
> >>Hi Akashi,
> >>
> >>On 28 May 2018 at 01:59, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote:
> >>>When I tried to add a SD card to qemu's virt machine (2.10.0) as,
> >>>         ------
> >>>         -device sdhci-pci \
> >>>         -device sd-card,drive=my_sd \
> >>>         -drive if=none,id=my_sd,format=raw,file=/path/my/sd.img
> >>>         ------
> >>>u-boot doesn't configure a SDHCI controller properly and an attached
> >>>device is never detected.
> >>>
> >>>Digging into the code, I found
> >>>* reading BAR5 in dm_pciauto_setup_device() shows BAR5 is a 32-bit address,
> >>>* pciauto_region_allocate() allocates a 64-bit address (0x80.ABCD.0000)
> >>>   to BAR5 as res->bus_lower is 0x80.0000.0000
> >>>* Upper 32-bit value is not written back to BAR5 because of !found_mem64
> >>>   (BAR5 is the last one and no succeeding BAR anyway.)
> >>>
> >>>On the other hand,
> >>>* Qemu defines two PCI memory regions for MMIO:
> >>>         (from qemu's hw/arm/virt.c)
> >>>         ------
> >>>         [VIRT_PCIE_MMIO] =          { 0x10000000, 0x2eff0000 },
> >>>         [VIRT_PCIE_PIO] =           { 0x3eff0000, 0x00010000 },
> >>>         [VIRT_PCIE_ECAM] =          { 0x3f000000, 0x01000000 },
> >>>         [VIRT_MEM] =                { 0x40000000, RAMLIMIT_BYTES },
> >>>         /* Second PCIe window, 512GB wide at the 512GB boundary */
> >>>         [VIRT_PCIE_MMIO_HIGH] =   { 0x8000000000ULL, 0x8000000000ULL },
> >>>         ------
> >>>* A PCI card is configured in decode_regions() so that
> >>>   'hose' has only one entry per each type of memory regions.
> >>>   This behavior was introduced by Simon's patch:
> >>>         ------
> >>>         commit 9526d83ac5a
> >>>         Author: Simon Glass <sjg@chromium.org>
> >>>         Date:   Thu Nov 19 20:26:58 2015 -0700
> >>>
> >>>             dm: pci: Support decoding ranges with duplicate entries
> >>>         ------
> >>>* As a result, MMIO region (0x1000.0000-0x2eff.0000) is overwritten
> >>>   and MMIO_HIGH is the only one available at runtime.
> >>>
> >>>I believe that this behavior is the root cause of my issue, and
> >>>by reverting the patch mentioned above, everything works fine.
> >>>
> >>>While I understand a concern mentioned in the commit message,
> >>>there should be a better way to manage the case.
> >>
> >>There was a series that changed things in this area. Can you take a look?
> >>
> >>    PCI: dm: Ignore 64-bit memory regions if CONFIG_SYS_PCI_64BIT not set
> >
> >Ah, I didn't know that, but it seems to me that it is still insufficient.
> >This hack won't work on 32-bit PCI card. I found another patch from Tuomas:
> 
> Did you try it? As of today's master all of the patches are applied and at
> least the e1000 NIC and the Intel AHCI card that I tested works.
> The effect of the commit is to indeed avoid the problem you mentioned:

Yes, I ran my patch but *with* CONFIG_SYS_PCI_64BIT.

> >>> * As a result, MMIO region (0x1000.0000-0x2eff.0000) is overwritten
> >>>    and MMIO_HIGH is the only one available at runtime.
> 
> Note that even on aarch64, CONFIG_SYS_PCI_64BIT is *not* set by default.
> And on ARM we would need to skip that region in U-Boot anyway because
> we don't have the means to access physical addresses above the 4GB
> boundary with the CPU using U-Boot's identity-mapped page tables.

Maybe you're right regarding aarch64, but the issue is not about arm/arm64
but PCI configuration. Some arch/machines, freescale mostly?, have
already enabled CONFIG_SYS_PCI_64BIT. I'm afraid that there may be
a possibility that your patch breaks them.

Thanks,
-Takahiro AKASHI

> 
> >---
> >         commit d71975ae6e0
> >         Author: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
> >         Date:   Mon May 14 19:38:13 2018 +0300
> >
> >             PCI: autoconfig: Don't allocate 64-bit addresses to 32-bit only
> >             resources
> >---
> >
> >This approach looks too conservative if 32-bit window is also available,
> >in addition to 64-bit space, as in the case of qemu-arm.
> 
> Yes, the patch is very minimal - I just wanted to fix the silent truncation
> of 64-bit addresses to 32-bit addresses and complain instead, nothing more.
> 
> (As the default config of qemu_arm* doesn't have CONFIG_SYS_PCI_64BIT,
> the condition won't actually trigger in practice).
> 
> >I'd like to propose supporting at least two type of PCI memory regions,
> >low mem (normal case) and high mem.
> >Attached is my experimental implementation for this although I might have
> >made any mistake as I'm not very much familiar with PCI specification.
> >
> 
> Yes, in theory it could be useful for some future hardware, but for QEMU
> point of view the current situation of totally ignoring the 64-bit mem region
> is probably good enough, given that most of the useful hardware that QEMU
> can enable is limited to 32-bit addressing anyway.

  reply	other threads:[~2018-06-01  7:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-28  7:59 [U-Boot] inappropriate PCI configuration on arm64 qemu? AKASHI Takahiro
2018-05-30 19:18 ` Simon Glass
2018-05-31  5:05   ` AKASHI Takahiro
2018-05-31 10:32     ` Tuomas Tynkkynen
2018-06-01  7:21       ` AKASHI Takahiro [this message]
2018-06-01 10:20         ` Tuomas Tynkkynen

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=20180601072121.GO30789@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.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
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