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

Mark Kettenis mark.kettenis at xs4all.nl
Fri May 24 22:16:06 UTC 2019 

> From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> Date: Thu, 23 May 2019 19:13:20 +0100
> Cc: Leif Lindholm <leif.lindholm at linaro.org>, Marcin Wojtas <mw at semihalf.com>,
>         edk2-devel-groups-io <devel at edk2.groups.io>,
>         Jan Dąbroś <jsd at semihalf.com>,
>         Grzegorz Jaszczyk <jaz at semihalf.com>,
>         Kostya Porotchkin <kostap at marvell.com>, Jici Gao <Jici.Gao at arm.com>,
>         Rebecca Cran <rebecca at bluestop.org>, kettenis at openbsd.org
> Content-Type: text/plain; charset="UTF-8"
> 
> 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 seems that that last bit isn't working...

> > 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.

Seems to work fine.  The EFI shell and OpenBSD bootloader prompt show
up on both the framebuffer and the serial console.  Here is a dmesg:


OpenBSD 6.5-current (GENERIC.MP) #2: Fri May 24 12:25:38 CEST 2019
    kettenis at caldara.sibelius.xs4all.nl:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 4095279104 (3905MB)
avail mem = 3936260096 (3753MB)
mainbus0 at root: ACPI
cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p1
cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu0: 512KB 64b/line 16-way L2 cache
efi0 at mainbus0: UEFI 2.7
efi0: EDK II rev 0x10000
apm0 at mainbus0
psci0 at mainbus0: PSCI 1.1, SMCCC 1.1
ampintc0 at mainbus0 nirq 352, ncpu 4 ipi: 0, 1: "interrupt-controller"
ampintcmsi0 at ampintc0: nspi 32
ampintcmsi1 at ampintc0: nspi 32
ampintcmsi2 at ampintc0: nspi 32
ampintcmsi3 at ampintc0: nspi 32
agtimer0 at mainbus0: tick rate 25000 KHz
acpi0 at mainbus0: rev 2
acpi0: sleep states
acpi0: tables DSDT FACP MCFG GTDT APIC PPTT SPCR VFCT
acpi0: wakeup devices
acpimcfg0 at acpi0
acpimcfg0: addr 0xe0008000, bus 0-0
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
ahci0 at acpi0 AHC0 addr 0xf2540000/0x2000 irq 114: AHCI 1.0
scsibus0 at ahci0: 32 targets
ahci1 at acpi0 AHC1 addr 0xf4540000/0x2000 irq 338: AHCI 1.0
ahci1: port busy after first PMP probe FIS
ahci1: port busy after first PMP probe FIS
ahci1: port 1: 6.0Gb/s
scsibus1 at ahci1: 32 targets
sd0 at scsibus1 targ 1 lun 0: <ATA, Samsung SSD 850, EMT0> SCSI3 0/direct fixed naa.5002538d42110a27
sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin
xhci0 at acpi0 XHC0 addr 0xf2500000/0x4000 irq 113, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
xhci1 at acpi0 XHC1 addr 0xf2510000/0x4000 irq 112, xHCI 1.0
usb1 at xhci1: USB revision 3.0
uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
xhci2 at acpi0 XHC2 addr 0xf4500000/0x4000 irq 337, xHCI 1.0
usb2 at xhci2: USB revision 3.0
uhub2 at usb2 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1
com0 at acpi0 COM1 addr 0xf0512000/0x100 irq 51: ns16550, no working fifo
com0: console
"MRVL0110" at acpi0 not configured
"MRVL0110" at acpi0 not configured
"PRP0001" at acpi0 not configured
"PRP0001" at acpi0 not configured
acpipci0 at acpi0 PCI0
pci0 at acpipci0
0:0:0: mem address conflict 0xfffe0000/0x20000
radeondrm0 at pci0 dev 0 function 0 "ATI Radeon HD 7450" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
"ATI Radeon HD 6400 Audio" rev 0x00 at pci0 dev 0 function 1 not configured
"framebuffer" at mainbus0 not configured
cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p1
cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu1: 512KB 64b/line 16-way L2 cache
cpu2 at mainbus0 mpidr 100: ARM Cortex-A72 r0p1
cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu2: 512KB 64b/line 16-way L2 cache
cpu3 at mainbus0 mpidr 101: ARM Cortex-A72 r0p1
cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
cpu3: 512KB 64b/line 16-way L2 cache
cdce0 at uhub2 port 2 configuration 2 interface 0 "TP-LINK USB 10/100/1000 LAN" rev 2.10/30.00 addr 2
cdce0: address f4:f2:6d:18:1a:e2
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
bootfile: sd0a:/bsd
boot device: sd0
root on sd0a (8b9b61adc6331423.a) swap on sd0b dump on sd0b
initializing kernel modesetting (CAICOS 0x1002:0x677B 0x1043:0x3025 0x00).
radeondrm0: 1920x1080, 32bpp
wsdisplay0 at radeondrm0 mux 1
wsdisplay0: screen 0-5 added (std, vt100 emulation)

the

"framebuffer" at mainbus0 not configured

line comes up because radeondrm(4) takes over and kicks out the UEFI
framebuffer.  If I disable radeondrm(4) I get:

...
pci0 at acpipci0
0:0:0: mem address conflict 0xfffe0000/0x20000
"ATI Radeon HD 7450" rev 0x00 at pci0 dev 0 function 0 not configured
"ATI Radeon HD 6400 Audio" rev 0x00 at pci0 dev 0 function 1 not configured
simplefb0 at mainbus0: 800x600, 32bpp
wsdisplay0 at simplefb0 mux 1
wsdisplay0: screen 0-5 added (std, vt100 emulation)
...

instead.

This is a Radeon R5 230 card; here is some basic PCI info:

Domain /dev/pci0:
 0:0:0: ATI Radeon HD 7450
	0x0000: Vendor ID: 1002, Product ID: 677b
	0x0004: Command: 0007, Status: 0010
	0x0008:	Class: 03 Display, Subclass: 00 VGA,
		Interface: 00, Revision: 00
	0x000c: BIST: 00, Header Type: 80, Latency Timer: 00,
		Cache Line Size: 00
	0x0010: BAR mem prefetchable 64bit addr: 0x0000000800000000/0x10000000
	0x0018: BAR mem 64bit addr: 0x0000000810000000/0x00020000
	0x0020: BAR io addr: 0x00000000/0x0100
	0x0024: BAR empty (00000000)
	0x0028: Cardbus CIS: 00000000
	0x002c: Subsystem Vendor ID: 1043 Product ID: 3025
	0x0030: Expansion ROM Base Address: c0000000
	0x0038: 00000000
	0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
	0x0050: Capability 0x01: Power Management
		State: D0
	0x0058: Capability 0x10: PCI Express
		Link Speed: 5.0 / 5.0 GT/s, Link Width: x4 / x16
	0x0100: Enhanced Capability 0x0b: Vendor-Specific
	0x0150: Enhanced Capability 0x01: Advanced Error Reporting
	0x00a0: Capability 0x05: Message Signalled Interrupts (MSI)
		Enabled: yes
 0:0:1: ATI Radeon HD 6400 Audio
	0x0000: Vendor ID: 1002, Product ID: aa98
	0x0004: Command: 0000, Status: 0010
	0x0008:	Class: 04 (unknown), Subclass: 03 (unknown),
		Interface: 00, Revision: 00
	0x000c: BIST: 00, Header Type: 80, Latency Timer: 00,
		Cache Line Size: 00
	0x0010: BAR mem 64bit addr: 0x0000000810020000/0x00004000
	0x0018: BAR empty (00000000)
	0x001c: BAR empty (00000000)
	0x0020: BAR empty (00000000)
	0x0024: BAR empty (00000000)
	0x0028: Cardbus CIS: 00000000
	0x002c: Subsystem Vendor ID: 1043 Product ID: aa98
	0x0030: Expansion ROM Base Address: 00000000
	0x0038: 00000000
	0x003c: Interrupt Pin: 02 Line: ff Min Gnt: 00 Max Lat: 00
	0x0050: Capability 0x01: Power Management
		State: D0
	0x0058: Capability 0x10: PCI Express
		Link Speed: 5.0 / 5.0 GT/s, Link Width: x4 / x16
	0x0100: Enhanced Capability 0x0b: Vendor-Specific
	0x0150: Enhanced Capability 0x01: Advanced Error Reporting
	0x00a0: Capability 0x05: Message Signalled Interrupts (MSI)
		Enabled: no

X11 works to some extent, but there are artifacts.  Half the
characters in my xterms are missing, and there are some random
characters in places where they shouldn't be.  That may very well be
an OpenBSD issue though.  Strangely enough 3D acceleration seems to
work fine.

Cheers,

Mark

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

View/Reply Online (#41371): https://edk2.groups.io/g/devel/message/41371
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]
-=-=-=-=-=-=-=-=-=-=-=-

More information about the edk2-devel-archive mailing list