building RaspPi Images

[Warner Losh]

On Feb 11, 2013, at 10:14 AM, Tim Kientzle wrote:

>>>> 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?
> 
> Here are several answers:
> 
> 1) The immediate result of this change will make
> it *easier* to change the FDT.  Right now, most people
> are recompiling the kernel just to tweak the FDT.
> This change moves it out into a separate standalone
> file in the boot partition.  (You still need to compile
> the DTS, but you can at least change it and reboot
> without touching the kernel.)

This is good.

> 2) We're still debating the role of the FDT vis a vis
> end user customization.  Personally, I would like
> to find some more dynamic approach to handling
> pinmux at runtime.  (E.g., if you want to use a pin
> for gpio, you do this:
>   $ gpioctl 1 7 out   # Set gpio 1 7 for output, including pinmux change
>   $ gpioctl 1 7 on
> Similarly, I think that enabling uart2 should automatically
> adjust the pinmux appropriately.

These are also good, but we have a long ways to go in the kernel to get there. And there are limits to how far you can push this envelope.

However, enabling uart2 is also done through the FDT, at least in linux, but it takes care of these pesky details for the most part.

> 3) IIUC, the FDT concept came from the PowerPC
> world, where the FDT is provided by the ROM.
> It's not really a tool for customizing the system; it's a tool
> for describing the hardware available.

It is a tool to describe how the hardware is configured as well. It is the only place where you can find how things are wired together. That's its primary purpose. If you are customizing your hardware, you are wiring it together differently.

> 4) Ubldr already has tools for adjusting the FDT
> dynamically at boot time.  I just committed the
> online help for this "help fdt".  So you can indeed
> adjust the FDT via loader.rc.  That works today, even
> when the FDT is compiled into the kernel.
> 
>>> 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.
> 
>> I think the basic problem here is a desire to treat u-boot as if it were
>> a PC BIOS, but it lacks some of what a traditional BIOS allows a user to
>> do in terms of configuring optional hardware and storing that config.
> 
> Right now, we're using U-Boot for exactly two things:
> * Boot loader driver.   Rather than writing board-specific
>    drivers for ubldr for every board, we get to leverage U-Boot.
> * Providing the *default* FDT.
> 
> The code I circulated yesterday uses the following logic to find
> the FDT:
>  1) If an FDT was loaded into ubldr, use that.  (E.g., "load -t dtb filename")
>  2) If U-Boot provided an FDT, use that.
>  3) If the kernel has a compiled-in FDT, use that.

Yes, I like that.

Warner