From owner-freebsd-arm@freebsd.org Fri Mar 25 05:48:10 2016 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 978BEADCDAD for ; Fri, 25 Mar 2016 05:48:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 697721740 for ; Fri, 25 Mar 2016 05:48:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id m184so105557763iof.1 for ; Thu, 24 Mar 2016 22:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+vb/JcTWNY9peI2k5HgZhymXjpeoRLGXj5YARlemNMI=; b=0cp4eoNqjqR0axzmTUj2k0SXRPfAtb1dP0I5Hnvl15zox3Yg4ASoTmXaBGzVvb1g6M aSwCCyDdFDtuuWfVn+qTMYuR9IxAHdhfWXVUo6GaCfWCTsH8N4BHMDhgXU820wIXoxq0 4iAPwWVsUwN9nRKg2GiCrNx7S9fJBdLtYPx2Jd6fZ8iPIaOpbIp9cgYnj4KMCxA08F0S TbzOxMeoY4ZDdkA9F5KKfiTzU/wXO29Fk8V18tB8cpc7M3P1BnoHg3E5I1uVU1MsE7jY VLGygviaSQ9w4ClutlOKwCfrpOm73faVpP9T7ZbLSmU2nIEx6qok6k7+jmV58L75Isz+ WfMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+vb/JcTWNY9peI2k5HgZhymXjpeoRLGXj5YARlemNMI=; b=f7s0s/Q1FbuY7MlCFYG8a8bSGPe5cyCDaq6DDRPONXueNz/cHQZUxE5A7M/PpDG+5t wsHtkp/9srlPMYZWAchNJNX7iRtVAZ/+6n59V6CI1yGq0a8lCqrD65y26xUxYsnt2lo+ nC6iCd9Tptpka2e1ho6gNu1Bp+3qce7YNjRNh1k+B6Mzqbtgw7voYvPdVgarFp8cn2Y2 zMZAY0KUbdhOW2SFj4vLfHvA/lrKtVB4GQmJQOdclzz31STtYcc2LbH5vD4mNMCY19n5 pbLbuf1MeN202sZlC8vJ3m16ANpVT81uzK4vvEVPO06ta3cV9LKDCqP+IuvPAfax4+QE VXeQ== X-Gm-Message-State: AD7BkJIRfpPFmXd4WvvXH1UNHqM9OgkXGgjPFWgTdtcQIwuR5SgMfiXQqzVXZH/Q9tE+AN96pcnxlfYSpbU1dQ== MIME-Version: 1.0 X-Received: by 10.107.155.206 with SMTP id d197mr11685502ioe.135.1458884889742; Thu, 24 Mar 2016 22:48:09 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Thu, 24 Mar 2016 22:48:09 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20160325052509.GE48704@cicely7.cicely.de> References: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> <20160325052509.GE48704@cicely7.cicely.de> Date: Thu, 24 Mar 2016 23:48:09 -0600 X-Google-Sender-Auth: FsRT5etkqWqhTNrORX4qWP3fKdY Message-ID: Subject: Re: Booting kernel.bin directly on Raspberry Pi / external DTB support From: Warner Losh To: ticso@cicely.de Cc: Sylvain Garrigues , freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 05:48:10 -0000 On Thu, Mar 24, 2016 at 11:25 PM, Bernd Walter wrote: > On Thu, Mar 24, 2016 at 04:29:26PM +0100, Sylvain Garrigues wrote: > > Hello, > > > > I have written a small (ugly) patch to be able to boot a kernel directl= y > without the ubldr loader while still using an external DTB (Linux-style > booting may pass the DTB location pointer in the r2 register). > > The patch is here: https://reviews.freebsd.org/differential/diff/14577/ > > > > I tested my patch successfully with the QEMU emulator with the -dtb > option available in recent versions, using a VERSATILEPB kernel without > FDT_STATIC. > > # qemu-system-arm -M versatilepb -m 128M -kernel versatile.flash -cpu > arm1176 -dtb versatilepb.dtb > > FYI, once the kernel is built, here is the script to build the > versatile.flash (adapted from gonzo, no longer need to clear the r0-r3 > registers): https://reviews.freebsd.org/P92 < > https://reviews.freebsd.org/P92> > > > > I also tested successfully my patch on my Raspberry Pi 2 using U-BOOT > and the RPI2 kernel with my patch applied (and the LINUX_BOOT_ABI option)= : > > u-boot> fatload mmc 0 0x200000 kernel.bin > > u-boot> go 0x200000 > > > > That works. > > > > So now I thought I could even bypass u-boot and launch kernel.bin > directly from the Pi firmware??? But it doesn???t work, I don???t > understand why, and that is why I am writing here. > > Here is the config.txt which I thought would work: > > > > kernel=3Dkernel.bin (instead of u-boot.bin) > > kernel_address=3D0x200000 (line added because a FreeBSD kernel needs to= be > loaded on a 1MB or 2MB boundary) > > device_tree=3Drpi2.dtb > > device_tree_address=3D0x100 > > disable_commandline_tags=3D1 > > > > What am I missing? Is it even possible to boot kernel.bin directly on > the Pi (with my patch)? I found this static minimalist loader from Andrew > here: > https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c > < > https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c> > - does it mean such a loader is necessary before the kernel? > > > > Thanks, > > Sylvain > > > > PS: I know the =C2=AB official and supported =C2=BB way of booting Free= BSD on the > Pi is the u-boot + ubldr combination. I just would like to finish this > experiment and understand why kernel.bin cannot be booted directly. > > I don't know if it is part of ubldr, or if there is any additional code, > which runs before ubldr, but the Pis won't boot with the ARM CPU. > Somewhere in the boot path is GPU bootcode, which then enables the ARM > CPU. > You also need low level HW init, such as setting up the clocks and RAM, > which is not done in the Kernel. > What you are missing it the hardware init code that's in u-boot.bin. This code sets up the board after the on-board GPU loads it into the ARM's address space. That code sets up the ARM side of the world and hands off the code to ubldr which finds the dtb and does the normal /boot/loader things as well (loading modules, setting tunables and the like) then hands off to the kernel. You can eliminate ubldr without a huge amount of effort, as you've found. However, eliminating u-boot.bin is going to be a lot more work/ tl;dr: The interface between u-boot.bin and ubldr/kernel.bin is quite a bit different than between the initial bootstrap and u-boot.bin. So you can't just drop in kernel.bin and have it work without replicating that interface. Warner