From owner-freebsd-arm@freebsd.org Sat Feb 11 19:08:37 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 B2048CDB610 for ; Sat, 11 Feb 2017 19:08:37 +0000 (UTC) (envelope-from tony@tndh.net) Received: from express.tndh.net (express.tndh.net [IPv6:2001:470:e930:1240:20d:56ff:fe04:4c0a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EC341FA6 for ; Sat, 11 Feb 2017 19:08:37 +0000 (UTC) (envelope-from tony@tndh.net) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tndh.net; s=dkim; h=Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-Reply-To:References:Cc:To:From; bh=KatCD3sihZJhPsa4xisJl1wpvXUzEdozbuQLG2cUaLI=; b=AdZ7haY3J9XhmTskUsRjXLA9hxuJavSke/E1wuia77X65z9tOb+dYH0LlEixCkrKqnB/BfzrVy5fyMqN18T8aZ/8YgugQRW0chFVQOA+Ty90FwvzHx39C6fTgRGeNiVgmg00UVmAZcnVrlzFDqy0SAYKM2K43AK9hnSKZYPyd1uFHM5H; Received: from express.tndh.net ([2001:470:e930:1240:20d:56ff:fe04:4c0a] helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1ccd25-0005VX-74; Sat, 11 Feb 2017 11:08:35 -0800 From: "Tony Hain" To: "'Oleksandr Tymoshenko'" Cc: References: <0ee901d28406$052ed070$0f8c7150$@tndh.net> <20170211015231.GA56071@bluezbox.com> In-Reply-To: <20170211015231.GA56071@bluezbox.com> Date: Sat, 11 Feb 2017 11:08:28 -0800 Message-ID: <0f3901d2849a$3ac2ca40$b0485ec0$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCzikkuUoxhpHAkDcVcrtsdCslcNQH9hJ4To5IviqA= Content-Language: en-us X-SA-Exim-Connect-IP: 2001:470:e930:1240:20d:56ff:fe04:4c0a X-SA-Exim-Mail-From: tony@tndh.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on express.tndh.net X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.5 tests=ALL_TRUSTED,RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 Subject: RE: Questions about BBB/BBG dtb names vs. content X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on express.tndh.net) 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 19:08:37 -0000 > -----Original Message----- > From: Oleksandr Tymoshenko [mailto:gonzo@bluezbox.com] > Sent: Friday, February 10, 2017 5:53 PM > To: Tony Hain > Cc: freebsd-arm@freebsd.org > Subject: Re: Questions about BBB/BBG dtb names vs. content > > 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. Thanks for the background. I had seen comments about a transition, but not enough detail to figure out old vs. new. > > 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 That may be the intent, but as of FreeBSD 12.0-CURRENT #0 r313411: Wed Feb 8 00:04:14 PST 2017 they were separate files, not links: root@tic:~ # ls -l /boot/dtb total 248 -r--r--r-- 2 root wheel 33017 Feb 8 00:07 am335x-bone.dtb -r--r--r-- 2 root wheel 33801 Feb 8 00:07 am335x-boneblack.dtb -r--r--r-- 1 root wheel 33305 Feb 8 00:07 am335x-bonegreen.dtb -r--r--r-- 2 root wheel 33801 Feb 8 00:07 beaglebone-black.dtb -r--r--r-- 2 root wheel 33017 Feb 8 00:07 beaglebone.dtb -r--r--r-- 1 root wheel 31483 Feb 8 00:07 ufw.dtb Links are what I expected, and is why I asked for clarification. > > 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. Thanks for the pointer. I have been running dtc after the build to manually patch the file. There is still the open question about the "compatible" strings containing "-" while the file names do not. If that is what is coming from upstream and expected, fine. I just wanted to check to make sure something didn't get crossed up during the name changes. Hopefully I will get a green build done this weekend. Tony > > -- > gonzo