Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Apr 2019 23:32:38 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-arm@FreeBSD.org
Subject:   [Bug 237055] Ampere eMAG compatibility
Message-ID:  <bug-237055-7@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237055

            Bug ID: 237055
           Summary: Ampere eMAG compatibility
           Product: Base System
           Version: CURRENT
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: greg@unrelenting.technology

Created attachment 203420
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D203420&action=
=3Dedit
emag.multiuser.dmesg

Sooo, now that Packet has Ampere eMAG instances (c2.large.arm), of course
someone had to try FreeBSD and of course it's me=E2=80=A6 :D

tl;dr I managed to boot to multiuser with some hacks, but PCIe is busted, n=
eeds
support for more ACPI stuff. Verbose boot log is attached, I'll attach ACPI
tables and stuff too.

---

0. Installation

I used an Ubuntu 18.04 instance, rerooted to a ramdisk ( using the method I
described in https://community.online.net/t/freebsd-on-arm64/6678 ), resized
the Linux partition, added a new one, loop mounted a memstick image, dd'd it
onto the new partition, copied loader_lua.efi to the EFI partition, added a
GRUB entry to chainload that:

menuentry 'FreeBSD' {
  load_video
  insmod part_gpt
  insmod chain
  set root=3D'hd0,gpt1'
  chainloader /EFI/BSD/loader_lua.efi
}

and used https://github.com/mkatiyar/fuse-ufs2 to modify the UFS partition =
from
Linux. (As long as you don't copy files from the UFS partition *to itself*,=
 it
works fine lol. If you do that, it gets stuck in a 100% cpu loop)

1. Console

https://reviews.freebsd.org/D19507 is needed for any UART output now that o=
ne
part from there (not using the hardcoded regshift) has landed. Now we need =
to
hardcode it again but only for PL011.

But that's not all. For some reason, I'm not seeing userspace output
(/dev/console) even though the ACPI node for the console was picked up:

uart0: <PrimeCell UART (PL011)> iomem 0x12600000-0x12600fff irq 1 on acpi0
uart0: console (115200,n,8,1)
uart0: fast interrupt
uart0: PPS capture mode: DCD

2. Weird early memory access crashes

EFI runtime support (specifically, enumerating efirtc) crashed in efi_call(=
) at
efi_get_time+0x50. I disabled `options EFIRT`.

Then ACPI crashed in AcpiExSystemMemorySpaceHandler when reading:

  exfield-0369 ExReadDataFromField   : FieldRead [TO]:   Obj
0xfffffd0010b41980, Type 11, Buf 0xfffffd0010b62b10, ByteLen 8
  exfield-0372 ExReadDataFromField   : FieldRead [FROM]: BitLen 1, BitOff 6,
ByteOff 0
  exfldio-0395 ExAccessRegion        : [READ] Region [SystemMemory:0], Widt=
h 4,
ByteBase 0, Offset 0 at 000000001F10C004

I patched DSDT, removing OperationRegion CLKE from Device AHBC. The only th=
ing
that used this was Method _INI for Device I2C4, so I removed the body of th=
at
method as well.
Who cares about i2c on a server :) that allowed booting to proceed.

3. PCIe is screwed up

There's this interesting message for all PCI bridges:

pcib0: bus end mismatch! expected 255 found 31.

And some more interesting messages (for the last couple pcib's also with "I=
/O
port window" and "bar .. failed to allocate"):

pcib0: rman_reserve_resource: start=3D0x30000000, end=3D0x301fffff, count=
=3D0x200000
pcib0: pci_host_generic_core_alloc_resource FAIL: type=3D3, rid=3D32,
start=3D0000000030000000, end=3D00000000301fffff, count=3D0000000000200000,=
 flags=3D0
pcib1: failed to allocate initial memory window: 0x30000000-0x301fffff
pcib0: rman_reserve_resource: start=3D0x14080000000, end=3D0x14084ffffff,
count=3D0x5000000

PCIe cards actually don't work when these messages are present:

mlx5_core0: <mlx5_core> mem 0x14082000000-0x14083ffffff at device 0.0 on pc=
i1
mlx5_core0: ERR: Failed mapping initialization segment, aborting

Looking at Ampere's page
https://github.com/AmpereComputing/ampere-centos-kernel/wiki/Ampere-CentOS-=
Kernel-wiki

it seems like Linux needed to ACPI _DMA objects and IORT named components:

https://github.com/torvalds/linux/commit/4f0450af530e62b0217522cab4803b5a65=
dccc46
https://github.com/torvalds/linux/commit/c04ac679c6b86e4e36fbb675c6c061b409=
1f5810
https://github.com/torvalds/linux/commit/7ad4263980826e8b02e121af22f4f4c910=
3fe86d
https://github.com/torvalds/linux/commit/10d8ab2c15b9ef2f46c35e7c36781399d6=
f2cc82

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237055-7>