From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 27 02:54:11 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 335ADAB0 for ; Tue, 27 Nov 2012 02:54:11 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id DEB838FC12 for ; Tue, 27 Nov 2012 02:54:09 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qAR2rZlh042768; Tue, 27 Nov 2012 02:53:35 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id d6dwi4qya4bpjumxbqph6hcibs; Tue, 27 Nov 2012 02:53:34 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: FreeBSD on RaspberryPi Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <3CE258BC-0A80-428A-8535-D589C50ADA86@bluezbox.com> Date: Mon, 26 Nov 2012 18:53:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5020FB83-6EAA-49D5-A533-ED127AF956AB@freebsd.org> References: <31C904E6-F230-4187-AE32-F9A7B1A7C38E@freebsd.org> <4A5E03E5-3295-4FD4-9A06-7D1C4E9E0C12@freebsd.org> <9E4DA920-BE72-4AA0-8159-43205CDEF5CD@bluezbox.com> <1E75CEAC-32E8-4048-A1FB-DD59F996E22F@freebsd.org> <3CE258BC-0A80-428A-8535-D589C50ADA86@bluezbox.com> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1283) Cc: FreeBSD Hackers , Alexander Yerenkow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 02:54:11 -0000 On Nov 26, 2012, at 10:43 AM, Oleksandr Tymoshenko wrote: >=20 > On 2012-11-26, at 7:05 AM, Tim Kientzle wrote: >=20 >>=20 >> On Nov 25, 2012, at 11:46 PM, Oleksandr Tymoshenko wrote: >>=20 >>>=20 >>> On 2012-11-25, at 9:32 AM, Tim Kientzle = wrote: >>>=20 >>>>=20 >>>> On Nov 24, 2012, at 8:01 PM, Oleksandr Tymoshenko wrote: >>>>=20 >>>>>=20 >>>>> On 2012-11-24, at 4:47 PM, Tim Kientzle = wrote: >>>>>=20 >>>>>=20 >>>=20 >>> .. skipped .. >>>=20 >>>>> Tim, >>>>>=20 >>>>> I'm almost done with getting kernel working with latest raspberry = Pi firmware. Just need >>>>> to figure out how to make ubldr pass FDT pointer from u-boot to = kernel and handle=20 >>>>> /reserve/ information in ARM machdep code.=20 >>>>=20 >>>> Let me know if you need help with this. I've worked with >>>> the ubldr FDT code recently. >>>>=20 >>>>> Meanwhile I suggest editing .dts file manually. Fill out "display" = node properties with proper >>>>> display resolution and depth. Also add ukbd driver. That should = get you working console. >>>>=20 >>>> I'll try that. >>>>=20 >>>> I'm curious: why is this information coming from the DTS? >>>> That seems pretty complex; I thought that the >>>> console code would query this information via the mailbox >>>> interface. >>>=20 >>>=20 >>> It's either FDT blob or message box interface. Implementation = complexity is about the same. >>=20 >> My thinking: >> * Display resolution used by kernel has to match what the firmware = uses. So the kernel should either get the information from the firmware = or from the same place the firmware gets it from. >> * We want ubldr to remain generic, so I'm reluctant to put things = into it that are RaspberryPi-specific. >>=20 >> If the firmware is putting the values into the FDT, then having the = kernel get it from the FDT is another way for the kernel to get it from = the firmware, so that sounds okay. >>=20 >>=20 >>> But since we're getting other variables (like MAC address, memory = size) from FDT I decided >>> to be consistent and get all of them from there. >>=20 >> I don't know about MAC address. Memory size is handled generically = by ubldr using a standard interface to U-Boot, so it's not special to = RaspberryPi. The FDT editing is just a standard way for ubldr to pass = this to the kernel. >>=20 >>> The issue I'm facing is that ubldr gets FDT blob >>> either from file directly or from ELF kernel itself. While on = Raspberry Pi to works as follows: >>>=20 >>> - Firmware loads .dtb file from SD card to specified address >>=20 >> Does RaspberryPi firmware now load an FDT? > Yes, when requested by device_tree_address and device_tree = parameters in config.txt >=20 >>=20 >> Does the firmware now read the FDT to get its values for display = resolution, etc? >> (I don't really like this because a lot of people need to tweak the = display settings and it's hard to tell a 6-year-old how to edit and = recompile an FDT.) > No. firmware writes to .dtb display's native resolution (or the = one requested in config.txt) to it. Not vice versa.=20 > That's the way to pass this information to kernel.=20 >=20 >>=20 >>> - Fixes up values like amount of memory, reserved regions, UART and = clock frequencies,=20 >>> MAC address, display resolution. >>> - Passes control to next link in boot chain (e.g. U-Boot) >>=20 >> To be clear: You say the RPi firmware is already doing this editing? >>=20 >> So the ubldr just has to pass the RPi FDT to the kernel? If so, = that's a lot simpler. > Yes >=20 >>=20 >>> I'm thinking about adding compile-time constant FDT_BLOB_ADDRESS and = arrange possible >>> FDT sources in following priority: >>>=20 >>> - Check FDT_BLOB_ADDRESS (if defined) >>> - Check dtb file >>> - Check ELF kernel >>>=20 >>> Does it sound sane enough?=20 >>=20 >> If the RPi firmware always loads the FDT at a fixed address >> and the RPi firmware is using the FDT to configure itself, >> then it makes a lot of sense. >>=20 >> It would be nice to do this without adding RPi-specific >> code to ubldr. >=20 > There will be no RPi-specific code. Just one more way to specify = location of generic FDT blob.=20 This all sounds good then. So we can put the FreeBSD .dts file on the MSDOS Boot partition, then: * Firmware will load it into memory and add display information. * ? ubldr will access the FDT and add memory information and MAC = address info ? * Kernel will then load it and use it to initialize. Maybe another possibility would be to script ubldr and have it load the = FDT from the correct location in memory. ubldr already knows how to = load an FDT and how to pass that FDT to the kernel. Tim