From owner-freebsd-arm@freebsd.org Mon Jan 25 20:15:36 2021 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 2A83B4F067A for ; Mon, 25 Jan 2021 20:15:36 +0000 (UTC) (envelope-from max@stucchi.ch) Received: from mailout.glevia.com (mailout.glevia.com [45.129.225.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4DPh1z1TXQz3HGZ for ; Mon, 25 Jan 2021 20:15:34 +0000 (UTC) (envelope-from max@stucchi.ch) Received: from Massimilianos-MacBook-Pro.local (unknown [45.129.224.254]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by mailout.glevia.com (Postfix) with ESMTPSA id 61D7122021 for ; Mon, 25 Jan 2021 20:15:33 +0000 (UTC) Reply-To: max@stucchi.ch Subject: Re: FreeBSD on RPI Compute Module 3+ 32G To: freebsd-arm@freebsd.org References: From: Massimiliano Stucchi Message-ID: Date: Mon, 25 Jan 2021 21:15:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DPh1z1TXQz3HGZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of max@stucchi.ch designates 45.129.225.5 as permitted sender) smtp.mailfrom=max@stucchi.ch X-Spamd-Result: default: False [-3.20 / 15.00]; HAS_REPLYTO(0.00)[max@stucchi.ch]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:45.129.225.5]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[45.129.225.5:from]; ASN(0.00)[asn:58280, ipnet:45.129.224.0/22, country:CH]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[max]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[stucchi.ch]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[45.129.225.5:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 20:15:36 -0000 Hi, I continue this solo thread with some news, as I spoke too soon. On 25/01/2021 10:43, Massimiliano Stucchi wrote: > > Hi, > > On 04/01/2021 15:03, Massimiliano Stucchi wrote: >> >> I have recently received a turingPi and a bunch of compute modules 3+ >> 32G, and I started playing with them. > >> However, my modules have a 32G built-in eMMC, and the boot just turns >> into a series of timeouts related to the MMC. > > I'd like to report that with the new 13-ALPHA2 images and the latest > DTD, the module boots up and works fine. I was able to boot, to configure everything and run it for a while. As long as you don't cut power to the module abruptly, it works. It has already happened to me twice that, after simply removing the module from its socket, it enters a state where it is not able to completely boot anymore. It stops after probing ue0 and after recognising the keyboard. It is not a hang, since if I press ctrl+alt+canc it does a clean reboot, but it just stops the boot there, as if it's waiting for something that is not probing. In a normal boot sequence, after the messages I see there would be ue0 going down, then up, and then I would get the login prompt. If anyone is willing to have a look, I can setup access to a serial console connected to the module. Ciao! -- Massimiliano Stucchi MS16801-RIPE