[edk2-devel] [edk2-platforms: PATCH v2 00/14] Armada7k8k PCIE support

[Ard Biesheuvel]

On Thu, 23 May 2019 at 19:02, Mark Kettenis <kettenis at jive.eu> wrote:
>
> > Date: Thu, 23 May 2019 15:14:27 +0100
> > From: Leif Lindholm <leif.lindholm at linaro.org>
> >
> > On Thu, May 23, 2019 at 03:27:47PM +0200, Mark Kettenis wrote:
> > > > From: Marcin Wojtas <mw at semihalf.com>
> > > > Date: Mon, 20 May 2019 17:27:13 +0200
> > > >
> > > > Hi,
> > > >
> > > > Thank you for thorough review of v1. I submit second
> > > > version of the Armada7k8k PCIE support. I addressed
> > > > all comments. There is no functional change to initial
> > > > patchset, but mostly clean-up and improvements - please
> > > > refer to the changelog below.
> > > >
> > > > The patches are available in the github:
> > > > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/pcie-upstream-r20190520
> > > >
> > > > I'm looking forward to your comments or remarks.
> > > >
> > > > Best regards,
> > > > Marcin
> > >
> > > Tested this on my mcbin running OpenBSD.  It incovers a small issue in
> > > our kernel which I'm fixing.  Otherwise this seems to work fine.
> > >
> > > So tested-by: Mark Kettenis <kettenis at openbsd.org> if that matters.
> >
> > Always helpful, thanks.
> >
> > Out of interest, what was the issue?
> > Could I still expect the 6.5 installer to run on this
> > hardware/firmware combo?
>
> That should still work fine.
>
> The issue is with mapping PCI ROMS, which currently fails with the new
> firmware due to an oversight in the OpenBSD code.  There are only a
> few OpenBSD drivers that attempt to map the PCI ROM.  But one of those
> is radeondrm(4) and I stuck an AMD graphics card into the PCIe slot on
> my machine.
>
> There is a bit of a firmware angle to this though.  The issue happens
> because the PCI ROM address register has been set to 0xfffe0000.  All
> the writable address bits in the register are set to 1.  While it is
> possible that the hardware comes up in that state, I suspect this is
> done by an attempt by the firmware to determine the size of the ROM
> that doesn't properly restore the original contents of the register.

UEFI deliberately leaves the ROM BARs unassigned, in order to avoid
wasting valuable 32-bit PCI MMIO space. It enables the BAR temporarily
to load the ROM, and dispatches it if it can. After that, it changes
the BAR back to the old unassigned value.

> It may be related to the following messages that are printed by the
> firmware:
>
> Image type X64 can't be loaded on AARCH64 UEFI system.
> Unloading driver at 0x00000000000

That address value is quite unexpected.

> Connect: PcieRoot(0x0)/Pci(0x0,0x0): Not Found
>
> Hmm, that's actually interesting.  Maybe I should play with the X86
> emulator that Ard added recently to see if that gives me a framebuffer
> console.
>

Yes, if you add edk2-staging to your PACKAGES_PATH env variable, all
you need to do is add -D X64EMU_ENABLE to the build command line.

If you do end up testing this, could you please report back with the
result, i.e., the type of card, PCI PID/VID and whether it all worked
as expected? Thanks.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#41292): https://edk2.groups.io/g/devel/message/41292
Mute This Topic: https://groups.io/mt/31686565/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-