FreeBSD on RaspberryPi

[Oleksandr Tymoshenko]

On 2012-11-26, at 7:05 AM, Tim Kientzle <kientzle at freebsd.org> wrote:

> 
> On Nov 25, 2012, at 11:46 PM, Oleksandr Tymoshenko wrote:
> 
>> 
>> On 2012-11-25, at 9:32 AM, Tim Kientzle <kientzle at freebsd.org> wrote:
>> 
>>> 
>>> On Nov 24, 2012, at 8:01 PM, Oleksandr Tymoshenko wrote:
>>> 
>>>> 
>>>> On 2012-11-24, at 4:47 PM, Tim Kientzle <kientzle at freebsd.org> 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 kernel.
> 
>> 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:
>> 
>> - Firmware loads .dtb file from SD card to specified address
> 
> Does RaspberryPi firmware now load an FDT?
    Yes, when requested by device_tree_address and device_tree parameters in config.txt

> 
> 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. 
That's the way to pass this information to kernel. 

> 
>> - Fixes up values like amount of memory, reserved regions, UART and clock frequencies, 
>>  MAC address, display resolution.
>> - Passes control to next link in boot chain (e.g. U-Boot)
> 
> To be clear:  You say the RPi firmware is already doing this editing?
> 
> So the ubldr just has to pass the RPi FDT to the kernel?  If so, that's a lot simpler.
    Yes

> 
>> I'm thinking about adding compile-time constant FDT_BLOB_ADDRESS and arrange possible
>> FDT sources in following priority:
>> 
>> - Check FDT_BLOB_ADDRESS (if defined)
>> - Check dtb file
>> - Check ELF kernel
>> 
>> Does it sound sane enough? 
> 
> 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.
> 
> 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.