Date: Mon, 11 Feb 2013 11:01:22 -0700 From: Warner Losh <imp@bsdimp.com> To: Iain Young <iain@g7iii.net> Cc: freebsd-arm@freebsd.org Subject: Re: building RaspPi Images Message-ID: <21D847EF-A61F-4612-A301-D2FC1D3AFAB1@bsdimp.com> In-Reply-To: <5119245A.5070704@g7iii.net> 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> <5119245A.5070704@g7iii.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 11, 2013, at 10:03 AM, Iain Young wrote:
> On 11/02/13 16:26, Ian Lepore wrote:
>> On Mon, 2013-02-11 at 09:10 -0700, Warner Losh wrote:
>=20
> [SNIP]
>=20
>>>>> 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.
>>>>>=20
>>>>> Warner
>>>>=20
>>>> 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?
>>>=20
>>> 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...
>>=20
>> 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.
>>=20
>> 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.
>=20
> 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)
>=20
> For example, to enable UART3_CTS on pin 36 of P8, you do:
>=20
> echo 26 >/sys/kernel/debug/omap_mux/lcd_data10
>=20
> I'm not aware FreeBSD has any such mechanism at present.
Yea, we're late to the pinmux/pinctl/gpio party here :(
Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?21D847EF-A61F-4612-A301-D2FC1D3AFAB1>