From owner-freebsd-arm@freebsd.org Sun Nov 20 19:08:53 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 8EB91C4C64D for ; Sun, 20 Nov 2016 19:08:53 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 43099136A for ; Sun, 20 Nov 2016 19:08:53 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-qk0-x22b.google.com with SMTP id q130so326319150qke.1 for ; Sun, 20 Nov 2016 11:08:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AhhlUaetM6q8NcL4587gSeK066qn0JdvNtHJ4OovDy0=; b=E8sIGwXwuVnrM8wYMUgnU+udQP2tMBPqHkqb79F8pht4wcZjX6eWrlB2TROUdDCW+p 6byUic+DrJ47E+ovrj/rDsQZU0bFxBKYS/5lTolphj873Yz/E9NmGUi6zyTf1ciU9z4o 3Uy/I9AJN+vZoiYm/EPKun5AxvscWB0Pxw+0+1YBo5rGNC6aQEcH6TpCUox0CNAoGyTB 4sGI5/fWpqEuQqZX8bD0T3MZYbPjcY9QWfbun1WT7u166Mf/KW2tR3nxYnJYs4tyHmqQ wBrrZdb3Y9vfmGo7MRx9dk4cWLYri4tmGhyZ4JIv+qmv4MlPlgYQYdwXazZfTk677/70 LsyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AhhlUaetM6q8NcL4587gSeK066qn0JdvNtHJ4OovDy0=; b=F3Zs6nBNOma0PiiUhDCPANACPH+jVeDz7Z8y62i4PRMiogX7vRndZV2VrrL6Kceq/1 ScaBqfPHqKNcH/b0BpKGhwYuSogF1PifsEDFV8gJpET3y2U7ZHSIGtB91eI9Hp8y8+U+ d4hSo/eAwz7h94uDEdN15xRtxym9GWeZHc7msOVDs5vgZFo7tO0BL/IUf4UgseIG2ecq CuzdzWI21hwv1RkhzNsWl4/V4dPx44MkmxheO6HNqJX46D7CczBXDh0oaAn7AOJvBwK0 N9J6Tjx1DKL35ykWYuh8W4wf6gNU15zRmkk7uDi8AxHm1cjkV+IEep0zggBHxttL1MBZ SALg== X-Gm-Message-State: AKaTC026jBhpC8mE5nlTcSXpDoUGrlonGPqjTIk6Lm3X20jzMukqJ6eYvmsLqDyotGDTv336dxhhIc1xwMzU8Q== X-Received: by 10.55.153.4 with SMTP id b4mr13107083qke.163.1479668932415; Sun, 20 Nov 2016 11:08:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.210 with HTTP; Sun, 20 Nov 2016 11:08:52 -0800 (PST) In-Reply-To: <234108602.628399.1478324542467@mail.yahoo.com> References: <234108602.628399.1478324542467.ref@mail.yahoo.com> <234108602.628399.1478324542467@mail.yahoo.com> From: Lee D Date: Sun, 20 Nov 2016 14:08:52 -0500 Message-ID: Subject: Re: Low level boot loader for freebsd To: girivs82@yahoo.com Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Sun, 20 Nov 2016 19:08:53 -0000 On Sat, Nov 5, 2016 at 1:42 AM, Shankar Giri via freebsd-arm < freebsd-arm@freebsd.org> wrote: > Serious problems with blank emails, so I'm using my alternate email > address. Hopefully this will go through.-----------------------------------Just > an idea I'm throwing out. I decided to do a bit of baremetal coding on my > Jetson-TK1 that got me thinking. Right now FreeBSD relies on uboot as the > low level bootloader and ubldr uses the u-boot API to bootstrap on top of > it. I'm thinking of extending the functionality of ubldr to remove the > u-boot dependency and use our own baremetal lowlevel hookups (well, name > might have to be changed since it won't be using u-boot > anymore). Advantages:1. Low level bootstrapping code part of FreeBSD tree. > Using the libstand library and the low level hookups, we'd get the low > level bootloader compiled while building world+kernel.2. Sharing the same > fdt. Since the low level bootloader uses the same dts/dtsi files as the > kernel, there is no reason to have two of them. The same fdt can be shared > between the bootloader and the kernel. Theoretically we could still do that > now between u-boot and freebsd, but being maintained by different projects, > the shared dts will have an unavoidable dichotomy.3. Seamless > bootstrapping. Right now, the bootloader and kernel are completely separate > entities, so once the kernel takes control, it ends up having to initialize > a bunch of HW that the bootloader has already take care of. This makes > sense now because there are no guarantees on what has and has not been > initialized by u-boot and what could change in future. With the bootloader > part of the freebsd base, we might actually be able to just do post-init > work on the kernel and this could actually improve boot times (and in the > embedded world, this counts for a lot)4. Use our default toolchain. Clang > (binutils is unavoidable at this point till the llvm linker is mature). I > already compiled my bare-metal code on Jetson-TK1 using Clang+binutils and > it ran quite well, llvm has has gotten pretty mature at this point. I > stopped using gcc for my arm compilation a long time ago, even for the > freebsd kernel. Disadvantages:1. Embedded world is fragmented, too many > machine/arch specific variations. Code maintainability could be a > nightmare.2. Testing low level is difficult. You don't even have a uart > console in bare-metal, so you'll have to rely on JTAG (sometimes really > expensive lauterbachs) or poring through assembly. Plus we need to find > people with embedded hardware willing to test them.3. Adoptability. I don't > think people will warm up to a new bootloader soon, particularly those who > have u-boot experience. Without contributors, this will die a slow > agonizing death. What does the community think? Is this something that > could actually help? If yes, I'm willing to start working on a > proof-of-concept. My test vehicle would be the Jetson TK1. > I think this is a great idea and I really wonder why the FreeBSD world seems to be so enamored of u-boot. One reason that people choose FreeBSD over Linux for embedded work is because it avoids the difficulties of the GPL. But of course, u-boot is GPL. The nice thing about u-boot is that it is one program that can be configured for many platforms. However, for the embedded world, I think a better approach to booting would be to fully document the boot requirements of the kernel itself, so that we can all write our own bootloaders for our own highly customized embedded platforms. I have tried to boot freebsd myself from a standalone loader, skipping u-boot and ubldr. I've only had partial success so far. This is something that I am going to have to address in the coming months. My intent would be to post my techniques for booting from bare metal without ubldr as I figure it out. But it will be a few weeks at least before I can work on it again. Right now, my approach is: 1. Keep a copy of the FreeBSD kernel on my FAT32 boot partition, and load that instead of the one on the UFS partition. 2. Compile the FDT into the kernel. 3. Configure the peripherals in my boot loader before starting FreeBSD. The kernel seems to require that certain things be configured by u-boot. Part of the idea here is avoid having to include UFS code in the boot loader. This approach is able to start booting the kernel but fails when it gets to loading the SD-Card drivers. I think. It's been a while since I last tried it. I hope you'll keep us apprised of your progress as well. PS I am working on Xilinx Zynq. Lee