Date: Mon, 26 Nov 2012 10:43:36 -0800 From: Oleksandr Tymoshenko <gonzo@bluezbox.com> To: Tim Kientzle <kientzle@freebsd.org> Cc: FreeBSD Hackers <hackers@freebsd.org>, Alexander Yerenkow <yerenkow@gmail.com> Subject: Re: FreeBSD on RaspberryPi Message-ID: <3CE258BC-0A80-428A-8535-D589C50ADA86@bluezbox.com> In-Reply-To: <1E75CEAC-32E8-4048-A1FB-DD59F996E22F@freebsd.org> References: <31C904E6-F230-4187-AE32-F9A7B1A7C38E@freebsd.org> <CAPJF9w=-pgVsz3JkKcwq7ZRYUNKUdFdEvU0fZZzZrVxTRpLW3w@mail.gmail.com> <4A5E03E5-3295-4FD4-9A06-7D1C4E9E0C12@freebsd.org> <CAPJF9wk%2B_5F4PAu8bK6A=Lfup6Qi_5OUJOqWfcJRKLJmeGSqGg@mail.gmail.com> <B11C8BD8-1F6B-4300-9BC9-77CD81F9670E@freebsd.org> <CAPJF9wnk6qqAA3F69CokRrHOsAotbUDtQPOiZ=EuhO7ZfM2y0Q@mail.gmail.com> <EFED5426-7DF7-41DA-82B1-6FEAB21EA098@freebsd.org> <9E4DA920-BE72-4AA0-8159-43205CDEF5CD@bluezbox.com> <EBE2570F-E57F-42F7-A7A5-5291E8CD81F1@freebsd.org> <C706651B-ABBE-4CEC-96D9-A5214BFEC11D@bluezbox.com> <1E75CEAC-32E8-4048-A1FB-DD59F996E22F@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2012-11-26, at 7:05 AM, Tim Kientzle <kientzle@freebsd.org> 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 <kientzle@freebsd.org> 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 <kientzle@freebsd.org> =
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CE258BC-0A80-428A-8535-D589C50ADA86>