From owner-freebsd-arm@freebsd.org Mon Oct 26 04:39:46 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EAA74439E1E for ; Mon, 26 Oct 2020 04:39:46 +0000 (UTC) (envelope-from freebsd-arm@darkain.com) Received: from MTA-06-4.privateemail.com (mta-06-4.privateemail.com [198.54.122.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CKMZB2G3jz3SXc for ; Mon, 26 Oct 2020 04:39:46 +0000 (UTC) (envelope-from freebsd-arm@darkain.com) Received: from MTA-06.privateemail.com (localhost [127.0.0.1]) by MTA-06.privateemail.com (Postfix) with ESMTP id 993A460049 for ; Mon, 26 Oct 2020 00:39:38 -0400 (EDT) Received: from mail-il1-f169.google.com (unknown [10.20.151.243]) by MTA-06.privateemail.com (Postfix) with ESMTPA id 697156003F for ; Mon, 26 Oct 2020 04:39:38 +0000 (UTC) Received: by mail-il1-f169.google.com with SMTP id p16so7041399ilq.5 for ; Sun, 25 Oct 2020 21:39:38 -0700 (PDT) X-Gm-Message-State: AOAM530dL8BP/Dfaw4w1MMV2SRLqvAnQOBBF8D909JSQuoPGrNT4VJpA tPMPUFJ0AVHnWgjGdoqZIKIk8HE+CJi8YX1Dnok= X-Google-Smtp-Source: ABdhPJzAF6IhuilrZIN6HI0FinObfRyJZgJh4IYCt3TYqdM6xIlvE/bBYYk0ruu10T05BsNI/EQniZXLyNN0nf96YW4= X-Received: by 2002:a92:4142:: with SMTP id o63mr10352810ila.138.1603687177682; Sun, 25 Oct 2020 21:39:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vincent Milum Jr Date: Sun, 25 Oct 2020 21:39:26 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: FreeBSD under VMware ESXi ARM Fling To: "freebsd-arm@freebsd.org" X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 4CKMZB2G3jz3SXc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-arm@darkain.com designates 198.54.122.56 as permitted sender) smtp.mailfrom=freebsd-arm@darkain.com X-Spamd-Result: default: False [-2.58 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.934]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[198.54.122.56:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.54.122.32/27]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[darkain.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.994]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-0.35)[-0.351]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:22612, ipnet:198.54.122.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 04:39:47 -0000 As a follow up, the VMware devs have been looking into the SMP issue for FreeBSD support. First, they've identified one bug for sure on their end that will be fixed in ESXi ARM Fling v1.2. After that fix, the boot process was blocking later on. >From Cypou: "Got something! I'm not sure where is the bug (esxi or freebsd), but the virtual gic does not record cpu0 enabling its SGIs (IPIs) interrupts. By forcing that in the hypervisor, I got all 4 cores running happily" Source: https://twitter.com/cypou/status/1320578258740662273 So now it just needs to be determined if this bug is on the ESXi side or the FreeBSD side, and then we should be good! On Tue, Oct 20, 2020 at 11:47 AM Vincent Milum Jr wrote: > Most of those instructions are just for "update the RPi's firmware" - if > you're on a new enough firmware already, you can skip that entire section > involving Raspberry Pi OS. > > After that, they just provide an installer image which can be used to > install to either local storage, or remote network storage. It is being > treated more like a typical x86 workflow rather than what we're more > familiar with for ARM/SBC workflows. > > On Tue, Oct 20, 2020 at 11:40 AM Robert Crowston > wrote: > >> > According to the ESXi devs, there is no SIO controller currently, and I >> believe this is required for the virtual serial ports to work >> > https://flings.vmware.com/esxi-arm-edition/bugs/1104 >> >> I do think this a requirement. Indeed, a UART is detected in your dmesg: >> >> uart0: <16550 or compatible> mem 0x3fff03f8-0x3fff03ff irq 5 on ofwbus0 >> uart0: console (230400,n,8,1) >> >> Is it not exposed on the host? >> >> If we cannot debug, a verbose boot would at least add some colour. Could >> you add boot_verbose="YES" to /etc/loader.conf? >> >> I took a look at the instructions for getting this up and running on my >> own Pi. It is certainly a lot of instructions. It is a shame they do not >> just provide a .img I could flash to an sdcard. >> >> -- RHC. >> >> >>