On 2012-11-26, at 7:05 AM, Tim Kientzle <kient...@freebsd.org> wrote:
>
> On Nov 25, 2012, at 11:46 PM, Oleksandr Tymoshenko wrote:
>
>>
>> On 2012-11-25, at 9:32 AM, Tim Kientzle <kient...@freebsd.org> wrote:
>>
>>>
>>> On Nov 24, 2012, at 8:01 PM, Oleksandr Tymoshenko wrote:
>>>
>>>>
>>>> On 2012-11-24, at 4:47 PM, Tim Kientzle <kient...@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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
