Date: Mon, 11 Feb 2013 17:03:22 +0000 From: Iain Young <iain@g7iii.net> To: freebsd-arm@freebsd.org Subject: Re: building RaspPi Images Message-ID: <5119245A.5070704@g7iii.net> In-Reply-To: <1360600007.4545.98.camel@revolution.hippie.lan> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <E691571B-EA19-4485-BB02-7486685B44C7@bsdimp.com> <1360598511.4545.92.camel@revolution.hippie.lan> <DCA761EF-FAE4-4BC9-AE33-D9F55C8ABB16@bsdimp.com> <1360600007.4545.98.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/02/13 16:26, Ian Lepore wrote:
> On Mon, 2013-02-11 at 09:10 -0700, Warner Losh wrote:
[SNIP]
>>>> The real solution here is to get the FDT plumbed through from the boards primary boot strap code into our code. Linux requires that this be passed in via like r2 for Linux to boot. We should make use of that too.
>>>>
>>>> Warner
>>>
>>> I'm seeing an essential conflict here in the mission of FDT data. If
>>> changing the FDT is the way an end user customizes things like pinmux
>>> assignments ("I need these pins for gpio, not another uart"), then how
>>> can we just accept a cannonical hardware description from low-level boot
>>> code we have no control over?
>>
>> If you are going to do crazy things like this, then you supply your own custom FDT. If you use the board in its stock configuration, then you use the thing from the boot loader. If you hack the board, you have to hack the FDT to match...
>
> That's a massively unsatisfying answer. It makes sense for something
> like a DreamPlug that's sold as a consumer unit; the phrase "stock
> config" makes some sense there.
>
> What's the stock configuration of a BeagleBoard? Pretty much every ball
> on the chip is brought out to one of two headers on the board so that
> you can use the board for virtually anything you want.
Note: Linux also allows you to change the pinmux stuff once you've
booted (It brings them up with their "default" mux setting, then you
can change it by poking around in /sys/kernel/debug/omap_max)
For example, to enable UART3_CTS on pin 36 of P8, you do:
echo 26 >/sys/kernel/debug/omap_mux/lcd_data10
I'm not aware FreeBSD has any such mechanism at present.
Iain
(who's svn co of /usr/src has finally finished, and will now start
buildworld and buildkernel after that before testing his patch
to enable UARTS1-4)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5119245A.5070704>