From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 26 18:43:58 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 A7CCC70F; Mon, 26 Nov 2012 18:43:58 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 09CEA8FC14; Mon, 26 Nov 2012 18:43:57 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.67]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Td3es-0004TI-K3; Mon, 26 Nov 2012 10:43:56 -0800 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: FreeBSD on RaspberryPi From: Oleksandr Tymoshenko In-Reply-To: <1E75CEAC-32E8-4048-A1FB-DD59F996E22F@freebsd.org> Date: Mon, 26 Nov 2012 10:43:36 -0800 Message-Id: <3CE258BC-0A80-428A-8535-D589C50ADA86@bluezbox.com> 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> To: Tim Kientzle X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-11-26, at 7:05 AM, Tim Kientzle wrote: > > On Nov 25, 2012, at 11:46 PM, Oleksandr Tymoshenko wrote: > >> >> On 2012-11-25, at 9:32 AM, Tim Kientzle wrote: >> >>> >>> On Nov 24, 2012, at 8:01 PM, Oleksandr Tymoshenko wrote: >>> >>>> >>>> On 2012-11-24, at 4:47 PM, Tim Kientzle wrote: >>>> >>>> >> >> .. skipped .. >> >>>> Tim, >>>> >>>> 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 >>>> /reserve/ information in ARM machdep code. >>> >>> Let me know if you need help with this. I've worked with >>> the ubldr FDT code recently. >>> >>>> 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. >>> >>> I'll try that. >>> >>> 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. >> >> >> It's either FDT blob or message box interface. Implementation complexity is about the same. > > 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. > > 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. > > >> 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. > > 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Mon, 26 Nov 2012 18:43:58 -0000 On 2012-11-26, at 7:05 AM, Tim Kientzle wrote: >=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 > 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 >> - 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 >> 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. There will be no RPi-specific code. Just one more way to specify = location of generic FDT blob.=20=