Date: Tue, 22 Jan 2019 21:39:59 +0300 From: Greg V <greg@unrelenting.technology> To: Martin Karrer <martin@bmalum.com> Cc: freebsd-arm@freebsd.org Subject: Re: ARM Graviton AWS Processor (AMI Image) Message-ID: <1548182399.2864.0@smtp.migadu.com> In-Reply-To: <010201686fe5047f-ed14af85-2b25-4480-a62a-a893f062eedd-000000@eu-west-1.amazo nses.com> References: <79CC79B9-81AF-4563-BABE-429E6A57F476@bmalum.com> <010201686fe5047f-ed14af85-2b25-4480-a62a-a893f062eedd-000000@eu-west-1.amazonses.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 21, 2019 at 1:11 PM, Martin Karrer <martin@bmalum.com>=20 wrote: > Hello, > This is my first message on the mailing list, please forgive me for=20 > making mistakes =F0=9F=98=89 >=20 > My question is if there are any plans yet to support the Graviton ARM=20 > instances of AWS? >=20 > We have a heavy load on FreeBSD and would also use the ARM instances.=20 > Are there any other interested parties? >=20 > I would be happy to donate my time and help. I have tried this. It should work very well in theory, e.g. the network=20 card driver (if_ena) compiles with no changes for aarch64, and in fact=20 NetBSD has ported this driver and is up and running on these instances:=20 https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D4623 But my result with FreeBSD was: nothing on the console after loader.efi=20 hands control to the kernel. My build patches: https://reviews.freebsd.org/D18372 &=20 https://reviews.freebsd.org/D18371 Unfortunately, AWS still has a read-only serial console (WTF?!), so=20 debugging systems there is a very frustrating experience of "stop=20 instance, detach disk, attach it to a running instance, do changes,=20 reattach back, start". And it feels like each of these steps runs=20 sleep(10000) when handling requests. I probably didn't see anything because the serial port wasn't=20 configured. Seems like AWS in their infinite wisdom have decided to=20 only provide their fancy PCIe based serial port. I have tried adding=20 its PCI ID to various places, configuring various boot variables with=20 the memory address that Linux/ACPI shows for that device, etc. but that=20 didn't help. =
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1548182399.2864.0>