From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 03:49:28 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AE406484 for ; Mon, 11 Feb 2013 03:49:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4D61B374 for ; Mon, 11 Feb 2013 03:49:27 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h2so5884987oag.10 for ; Sun, 10 Feb 2013 19:49:27 -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=KNRteHA4+qX/CdMUKoiC8FIW59atiKYcWaXvWS701hc=; b=RmDxFbYnT3hkUW2Y+ZOugd2fnMXwoMSd7yA1YKNC2d6CNZ8y0BPSCRWkTeCKOQ0s3K Pw4kC3+lcMiZUyUgrb85woXjuAcVTYEG/+olUCdxYAglHcDiQZU7c7EdHPRxpZni/TLE 6WSZhHp/mQn5lkXj3SHFrbEG6/N/unbR9ssfoysBJlywscvMRar6K+mv7nh4x2TGAaUg Dftxo9K6lKn0qqD6xz+ZO+ZOitzHdTkIQXB5DvOis9rYO23VW3TuhpWCzMb3cVCm4MIm r6jt7xQOs9H8YHGiSpf81vTvkofFUNEYqJ/kEa9KjSwuMptHxKzru7yqWVVLvFCVgQqT /Jpg== X-Received: by 10.182.73.67 with SMTP id j3mr9494953obv.102.1360554567373; Sun, 10 Feb 2013 19:49:27 -0800 (PST) Received: from 53.imp.bsdimp.com ([209.117.142.2]) by mx.google.com with ESMTPS id y4sm48957504oea.7.2013.02.10.19.49.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Feb 2013 19:49:26 -0800 (PST) Sender: Warner Losh Subject: Re: building RaspPi Images Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: <1339E085-2B31-485D-9EED-9D0AFB7664C5@kientzle.com> Date: Sun, 10 Feb 2013 20:49:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F7AE905-7A08-48EE-8905-8D688266739A@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <8087503F-BE98-45B9-888B-044D9DA58B80@bsdimp.com> <20130210212025.009ee482@bender> <1339E085-2B31-485D-9EED-9D0AFB7664C5@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlQcrzBkT2gTVyP9ttph344wlUu9y+sc149m/ITGKyGdbUk0AQIyo/I9Bq0DpcbLGrGHvZc Cc: 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 03:49:28 -0000 On Feb 10, 2013, at 5:39 PM, Tim Kientzle wrote: > On Feb 10, 2013, at 6:56 AM, Warner Losh wrote: >>=20 >> Right, we're doing it wrong. Or rather, we're using the standalone = interface when we should be using the linux interface. >=20 > So you think that ubldr should startup like a Linux kernel? > That's an interesting idea=85 Hmmmm=85.. If it isn't getting the FDT via the alternate interface, then yes. >> The stand alone interface should, in theory, provide us with the DTB, = but the code that is in ubldr doesn't seem to be reliably getitng this = image. >=20 > I don't think anyone has spent time on this. We've > just been focused on "making it work" and the compiled-in > DTB does work for any single board. Ah, that makes sense. I just know the theory, not the practice. I = haven't had time for armv6 stuff... >> uboot is supposed pass dtb to us. We're using the self-hosted = interface, rather than the linux interface, to boot. uboot is supposed = to have a jump table that we find and use to get the dtb from it, but = that code seems to not be working reliably. >=20 > The interface works (I've spent a fair few hours fixing it), > but I don't think anyone has tried getting the DTB from it. We should try... > Any ideas for addressing the load-address problem? > E.g., RPi has initial RAM mapped starting at address 0 > and BeagleBone starts with RAM mapped to 0x80000000. > Right now, that means we can't even share ubldr across > those two systems because it has to be linked differently. I'm unsure how Linux deals with it... I'm guessing that if we can turn = on the vm translation early enough, then this won't matter... >> uboot gives linux images the DTB w/o any problem today, but you have = to run mkimage to get the image file to load into uboot for that to = work. >=20 > Actually, the statement above isn't quite right for RPi. > Linux on RPi doesn't use U-Boot. Well, all Linux kernels require DTBs today, although some compile it = into the image... > So we're currently > using: >=20 > RPi boot loader =3D> U-Boot =3D> ubldr =3D> kernel. >=20 > The RPi boot loader does load the FDT and will pass > it to a Linux kernel, but I don't think U-Boot implements > that part of the linux kernel startup (which is why ubldr > on RPi looks at a particular address in RAM to get > the FDT from the RPi boot loader). Ah, it implements the standard interface. That should be an option, = since it is relatively easy to do. Maybe I should give in and get a RPi :) Warner