From owner-freebsd-arm@freebsd.org Tue Mar 1 06:56:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B8FCABB0E7 for ; Tue, 1 Mar 2016 06:56:22 +0000 (UTC) (envelope-from martin@waschbuesch.de) Received: from relay.waschbuesch.it (relay.waschbuesch.it [IPv6:2a00:cba0:0:100::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.waschbuesch.it", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D2931A82 for ; Tue, 1 Mar 2016 06:56:22 +0000 (UTC) (envelope-from martin@waschbuesch.de) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=waschbuesch.de; s=dkim; h=To:References:Message-Id: Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type; bh=FTLte7xs5DsLBRm9y7kPo6ogpxJNR2JyO6PDrD6v0d0=; b=OxbNWPI1UvyE 58fneRj+TPu4fHbGxNadWVL9QjkhaLBw8AtWVQAKRG6Bt+27FMiUcxiTATITSzJJrobJcBjZQJt6/ MsrlZe+HGncRF9Jfs63Ok5jjkdkAQuRRNwR3YJnjGHytAjaShHgP97ELGQlljl8u/g9DemSNlPdCr Evb+o=; Received: by relay.waschbuesch.it with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim) (envelope-from ) id 1aaeEC-0003Rj-QR for freebsd-arm@freebsd.org; Tue, 01 Mar 2016 06:56:16 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: FreeBSD on Utilite (revisited) From: =?utf-8?Q?Martin_Waschb=C3=BCsch?= In-Reply-To: Date: Tue, 1 Mar 2016 07:56:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8262C265-A9F6-4336-9A33-4A97BE7451F6@waschbuesch.de> <6531E2F1-0682-4220-B148-BA7061C50B79@waschbuesch.de> <20160229062941.4374611.32643.3487@gmail.com> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 06:56:22 -0000 > Am 29.02.2016 um 08:49 schrieb Oleksandr Tymoshenko = : >=20 >>=20 >> On Feb 28, 2016, at 11:18 PM, Martin Waschb=C3=BCsch = wrote: >>=20 >>=20 >>> Am 29.02.2016 um 07:29 schrieb Russell Haley : >>>=20 >>> It seems compulab's imx6 som is called the CM-FX6. There are some = imx6-cm-fx6 and imx6q-cm-fx6 files in their linux kernel on github? >>>=20 >>> = =E2=80=8Ehttps://github.com/utilite-computer/linux-kernel/tree/utilite/dev= el/arch/arm/boot/dts >>=20 >> Thank you, Russ. >>=20 >> There already is a dts file for the cm-fx6 in the FreeBSD kernel = sources >> for instance /usr/src/sys/gnu/dts/arm/imx6q-cm-fx6.dts >>=20 >> However, the same is true for the Wandboard >> /usr/src/sys/gnu/dts/arm/imx6qdl-wandboard.dtsi >> and yet, Crochet uses the files found under >> /usr/src/sys/boot/fdt/dts/arm/ >=20 > In early days of FDT support number of supported ARM boards was really > small and people tended to write their own DTS files from the scratch, > instead of using ones from Linux due to licensing concerns. These > DTS files were placed to boot/dts/fdt. As number of supported hardware > grew it became clear that this practice is a dead end, we can't keep > up with changes provided by vendors. So after some research it was > concluded that we can bring DTS files from Linux. I don't remember > exact reasoning but the gist of it: they're not code, they're set=20 > of facts about hardware. "Upstream" files were placed to gnu/dts. >=20 > Some of the files in boot/dts/fdt are just wrappers around > vendor-provided dts/dtsi files, fixing Linux-specific=20 > idiosyncrasies or adding new nodes. for instances, there > is no PRUSS node in Linux DTS for beaglebone, but=20 > boot/fdt/dts/arm/beaglebone-common.dtsi adds it. >=20 > You should be able to use .dts file in either directory, build system > checks boot/fdt first and then gnu/ AFAIR.=20 Thanks for that explanation. This makes sense now. >>=20 >> So, I went with the wandboard-quad.dts file from there, seeing as it = should be quite similar to my Utilite Pro. >> So far, no luck. Once the loader slurps in the compiled .dtb, the = system hangs with no further sign of activity. >=20 >=20 > Check stdout/stderr settings in =E2=80=9Cchosen=E2=80=9D node. Looks = like > imx6q-cm-fx6.dts uses UART4 for serial output while Wandboard=20 > quad uses UART0. That is a valuable piece of information, thanks! I also noticed that for IMX6 kernel config, ROOTDEV is hardcoded. Maybe = I am overlooking something, but why go to all the length of making sure = u-boot runs and loads ubldr to have loader capabilities and then not = specify the desired rootdev via loader but compile it into the kernel? Obviously, I do not know if the Wandboard supports it, but the Utilite = can boot from either mmc, usb or msata.=