From owner-freebsd-arm@FreeBSD.ORG Sun Feb 10 14:56:16 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 2AD6A4F9 for ; Sun, 10 Feb 2013 14:56:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by mx1.freebsd.org (Postfix) with ESMTP id EFB241B3 for ; Sun, 10 Feb 2013 14:56:15 +0000 (UTC) Received: by mail-ie0-f176.google.com with SMTP id k13so6719016iea.35 for ; Sun, 10 Feb 2013 06:56:15 -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=DlDmLFvDB236eIQaOPDh1HHdFfAMv4nC9h8rvyP5rps=; b=DnGZ/R+XeuP863PdE6gQFF9BqEzDtXHoRDYy+Ndqcb3NcUNz/iFT0rwDxe3YSuO5xQ jNqJF/ShhryCzU1HX8EouLidT/7auae2h3vTyOWIDZxSq4CavEPJhDyPuNKMY/dMOqOJ 2bJrbQACV8PpDvhn3ud/omuzfn2ilJAtRKFyjWSSoj+tdCgDzOvxb52hw7bHc4zW3+Xz jY/+JGzCyUkFlOtriX2FB5y7tAxC122qyJnCmJHP7lzczl4CxDZyyBkIjVCvWwKsAvD+ KhLt1b6IPF17BzFYu2xrKLSS7nwxYi5GFnC7xATgm0RL1fDJlTfA6Ef5t39Q3mFgCysa A2XQ== X-Received: by 10.50.187.225 with SMTP id fv1mr9756132igc.96.1360508175501; Sun, 10 Feb 2013 06:56:15 -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 fa6sm24181956igb.2.2013.02.10.06.56.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Feb 2013 06:56:14 -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: <20130210212025.009ee482@bender> Date: Sun, 10 Feb 2013 07:56:11 -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> <8087503F-BE98-45B9-888B-044D9DA58B80@bsdimp.com> <20130210212025.009ee482@bender> To: Andrew Turner X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkI5pjtfTEeRv/LsaJ0E3PHrWb1UySEaXUhjrjxVEsVk2GFtcBh2gNvejhVFUeu5sVXs/VZ 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: Sun, 10 Feb 2013 14:56:16 -0000 On Feb 10, 2013, at 1:20 AM, Andrew Turner wrote: > On Sun, 10 Feb 2013 00:47:38 -0700 > Warner Losh wrote: >=20 >>=20 >> On Feb 10, 2013, at 12:18 AM, Tim Kientzle wrote: >>=20 >>> On Feb 9, 2013, at 11:07 PM, Warner Losh wrote: >>>=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 >>> I haven't dug into this yet, but there's a mismatch somewhere >>> between the RPi first-stage boot loader, U-Boot, and our ubldr. >>>=20 >>> I briefly tried loading our kernel straight from the RPi >>> first stage boot loader (dropping U-Boot and ubldr >>> phases) but didn't get very far with it. >>=20 >> Our ubldr currently ignores r2 on boot, and tries to get the FDT via >> a different uboot interface, but I'm thinking that part is broken...=20= >=20 > As I understand it ubldr is an elf image. We use the bootelf command > from U-Boot to jump into it. This command executes entry(argc, argv); > to run ubldr. As argc is an int and argv is a pointer these will be in > r0 and r1 respectively, as such is shouldn't look at r2. Right, we're doing it wrong. Or rather, we're using the standalone = interface when we should be using the linux interface. 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. If we can't = get it reliably from the standalone interface, we should switch to the = linux interface, where it should be trivial to get it. > It looks like ubldr doesn't look at argc and argv, and should have no > need to unless we decide to have it take the address of the dtb on the > command line, or have some other data passed in from U-Boot. 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. 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. We sure shouldn't be passing an address of the dtb via a command line = argument. Warner=