From owner-freebsd-arm@freebsd.org Tue Jan 22 22:49:02 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1FB914B249F for ; Tue, 22 Jan 2019 22:49:01 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.223.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C0B374C52 for ; Tue, 22 Jan 2019 22:48:58 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Tue, 22 Jan 2019 22:47:45 +0000 Received: from [192.168.1.141] ([62.122.208.146]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id 573BB6F3-0646-4F4F-A6BD-14C41BE25C37.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Tue, 22 Jan 2019 22:47:44 +0000 Date: Tue, 22 Jan 2019 21:39:59 +0300 From: Greg V Subject: Re: ARM Graviton AWS Processor (AMI Image) To: Martin Karrer Cc: freebsd-arm@freebsd.org 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> X-Mailer: geary/lite-gnome~g3766af013824-dirty MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; bh=zAzfmxdCazfHcaXKeuVfVP9cl5v4L3qT1QtSUA3O+7o=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=aiTdRp+JY2uFsbDEcAdkup3Mtu+VuhDaGzg6dws+wjqcLCl31Q9j11OAKqP5COB8Cgzmau1zl0o/WIB+tCglsX2mqKzXO+FIRLIVSQ7m3XlAVAoY2Zh8xsq0W1HVdkxqtm/vDgqgm/iZalypVj/QVrLEylbM+gXBs3Z6yuGl1z0= X-Rspamd-Queue-Id: 6C0B374C52 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=aiTdRp+J; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 91.121.223.63 as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-6.71 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.223.63]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; MX_GOOD(-0.01)[aspmx1.migadu.com,aspmx2.migadu.com]; NEURAL_HAM_SHORT(-0.98)[-0.982,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.72)[ip: (-9.89), ipnet: 91.121.0.0/16(-4.32), asn: 16276(0.65), country: FR(-0.02)]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2019 22:49:02 -0000 On Mon, Jan 21, 2019 at 1:11 PM, Martin Karrer =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. =