From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 16:10:18 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 195F5226 for ; Mon, 11 Feb 2013 16:10:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x230.google.com (ia-in-x0230.1e100.net [IPv6:2607:f8b0:4001:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id DB66FBD6 for ; Mon, 11 Feb 2013 16:10:17 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id i18so6415787iac.7 for ; Mon, 11 Feb 2013 08:10:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=LU5uAO2EISRJ2KwtDMS//C9Yawq3zgmNbLv9qnJ3xjo=; b=midBjG3p7jnpKojFzdo1domPyWienTQZ6PAxTa0IjID8ni769F9JPoRQ4LqQ6W4/zI ocWMgPvHo9i8wnWevg1BJ+EGFNKbPUHpo1nDW0GzhIZSl9dGbGg1dc1/bl891HlRTGxf lUcbVdBvH4MfaTXknB8PdJqzwB/UzYcTIjPFkDTt3PIlpTDzjTqt8j/JNaVMd7gysmG2 AfAWmkrh+H8zP0HPou+A0AC1iC8VMKtRuetZmVPpBJASCRY8a/eH58pMpTaBiiZeiFfZ yN/dxBgzo2D57s3x+U50U9H05/2ZWg8pnWqzClUL3NuTyrYgLxyP2mcgF3mdnwCJwrPA oPEg== X-Received: by 10.50.236.42 with SMTP id ur10mr12443423igc.16.1360599017253; Mon, 11 Feb 2013 08:10:17 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id fa6sm28724689igb.2.2013.02.11.08.10.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Feb 2013 08:10:16 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1360598511.4545.92.camel@revolution.hippie.lan> Date: Mon, 11 Feb 2013 09:10:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <1360598511.4545.92.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQldQOdIHf1p6R3DQcDEY4jp4Z8ZBM6ypaQMpOa7kXegxsRel+hi8EqNCOzVe0qxG6QSZ7oa Cc: Tim Kientzle , freebsd-arm@FreeBSD.org, Brett Wynkoop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 16:10:18 -0000 On Feb 11, 2013, at 9:01 AM, Ian Lepore wrote: > On Sun, 2013-02-10 at 00:07 -0700, Warner Losh wrote: >> On Feb 10, 2013, at 12:03 AM, Tim Kientzle wrote: >>=20 >>> On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: >>>>=20 >>>> I was thinking that we should be able to generate a generic image = that >>>> will boot on both the Pi and the Bone. Maybe a config file that >>>> includes the needed drivers for both boards. >>>=20 >>> I've thought about this and believe it is pretty routine, >>> though I've not had time to actually try implementing it. >>>=20 >>> This specific combination is simplified by the fact >>> that the boot bits are so different, so you can just >>> put them all on the same SD card image. >>>=20 >>> There are a few pieces you'll need to work through: >>> 1. An MSDOS partition with all the boot bits from both systems >>> 2. A kernel with all of the drivers for both systems >>> 3. ubldr will need to identify the board somehow >>> 4. ubldr will need to obtain the correct FDT >>=20 >> uboot is supposed to be providing the correct FDT. IF we aren't using = it, we're doing FDT wrong and need to fix that. >>=20 >>> Except for #3, this should all be entirely routine. >>>=20 >>> For #4, the trick is to not compile any DTB into the >>> kernel. Instead, the DTB is given to the kernel by >>> the boot bits: >>>=20 >>> * For RPi, this already happens: the first-stage boot >>> loads a DTB, ubldr uses "fdt addr" to access that DTB >>> in a known location and then passes it to the kernel. >>=20 >> Doesn't the RPi's boot loader give our /boot/loader enough info to = get this without the fdt addr command? >>=20 >>> * For Beaglebone, you can use loader.rc commands to load >>> the proper DTB from the UFS partition. I'm using the following >>> on my BeagleBone right now: >>> /boot/beaglebone.dtb >>> /boot/loader.rc contains >>> load /boot/kernel/kernel >>> load -t dtb /boot/beaglebone.dtb >>> autoboot >>=20 >> why isnt' the beagle board's boot loader passing it to /boot/loader? >>=20 >>> This should be an afternoon's work for someone who already >>> has a good understanding of FreeBSD boot processes. >>=20 >> The real solution here is to get the FDT plumbed through from the = boards primary boot strap code into our code. Linux requires that this = be passed in via like r2 for Linux to boot. We should make use of that = too. >>=20 >> Warner >=20 > I'm seeing an essential conflict here in the mission of FDT data. If > changing the FDT is the way an end user customizes things like pinmux > assignments ("I need these pins for gpio, not another uart"), then how > can we just accept a cannonical hardware description from low-level = boot > code we have no control over? If you are going to do crazy things like this, then you supply your own = custom FDT. If you use the board in its stock configuration, then you = use the thing from the boot loader. If you hack the board, you have to = hack the FDT to match... Warner=