From owner-freebsd-arm@freebsd.org Sat Feb 11 01:52:34 2017 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 B4FC5CD9A05 for ; Sat, 11 Feb 2017 01:52:34 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 91900A66 for ; Sat, 11 Feb 2017 01:52:34 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1ccMrY-000EcM-Op; Fri, 10 Feb 2017 17:52:33 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v1B1qW4l056193; Fri, 10 Feb 2017 17:52:32 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Fri, 10 Feb 2017 17:52:31 -0800 From: Oleksandr Tymoshenko To: Tony Hain Cc: freebsd-arm@freebsd.org Subject: Re: Questions about BBB/BBG dtb names vs. content Message-ID: <20170211015231.GA56071@bluezbox.com> References: <0ee901d28406$052ed070$0f8c7150$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0ee901d28406$052ed070$0f8c7150$@tndh.net> X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Tony Hain (tony@tndh.net) wrote: > When I built 12 current the other day, I found some confusing dtb file > names. > First there were identical files : > am335x-bone.dtb beaglebone.dtb > am335x-boneblack.dtb beaglebone-black.dtb > > But there was not a matching one for green. Is that intentional? > am335x-bonegreen.dtb > > Then the content didn't match the names: > am335x-boneblack.dtb -- > compatible = "ti, am335x-bone-black", "ti, am335x-bone", "ti,am33xx"; > > am335x-bonegreen.dtb -- > compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", > "ti,am335x-bone", "ti,am33xx"; > > Aren't the strings in the compatible line supposed to match the file names? > Is there a reason there are identical files in the dtb path rather than a > link? > Is the fdt_file="" line required in loader.conf if the am335x file name > exists? > > I have the BBB running with fdt_file="beaglebone-black.dtb", and the changes > to it for turning on uart1. Should I have made the changes to the am335x > file instead, or should I create the beaglebone-green.dtb file for the BBG? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: tndh.net] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 01:52:34 -0000 Tony Hain (tony@tndh.net) wrote: > When I built 12 current the other day, I found some confusing dtb file > names. > First there were identical files : > am335x-bone.dtb beaglebone.dtb > am335x-boneblack.dtb beaglebone-black.dtb > > But there was not a matching one for green. Is that intentional? > am335x-bonegreen.dtb > > Then the content didn't match the names: > am335x-boneblack.dtb -- > compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx"; > > am335x-bonegreen.dtb -- > compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", > "ti,am335x-bone", "ti,am33xx"; > > Aren't the strings in the compatible line supposed to match the file names? > Is there a reason there are identical files in the dtb path rather than a > link? > Is the fdt_file="" line required in loader.conf if the am335x file name > exists? > > I have the BBB running with fdt_file="beaglebone-black.dtb", and the changes > to it for turning on uart1. Should I have made the changes to the am335x > file instead, or should I create the beaglebone-green.dtb file for the BBG? beaglebone*dtb is FreeBSD-specific DTB names, dts files for them were created in early days of FDT support. am335x-*dtb are upstream names, Linux and U-Boot use them as standard names. U-Boot can detect type of board in run-time and set fdt_file env variable based on that type. Until recently we had sysutils/u-boot-beaglebone port with custom FreeBSD-specific patch where this autodetect logic used beaglebone*dtb names. Recently it was converted to being slave port to sysutils/u-boot-master as a part of U-Boot ports unification effort. During this conversion aforementioned patch was deleted so now u-boot operates with am335x-*.dtb names. To be backward-compatible with previously built systems, that still refer to old-style names, we now create links, beaglebone.dtb is a link to am335x-bone.dtb and beaglebone-black.dtb is a link to am335x-boneblack.dtb. There was no FreeBSD-specific DTS for beaglebone green previously, so am335x-bonegreen.dtb does not have beaglebone* counterpart. At the moment any changes toboot/fdt/dts/arm/beagebone-*.dts are not going affect beagebone-*.dtb because these dtbs created as links, not generated. I have patch in review that fixes it and brings back old-style DTBs along with some fixes that are in upstream but haven't been merged to FreeBSD tree yet: https://reviews.freebsd.org/D9432 With current tree you need to move your uart1-related change to sys/gnu/dts/arm/am335x-boneblack.dts, regenerate dtbs and that should do the trick. -- gonzo