building RaspPi Images

[Warner Losh]

On Feb 11, 2013, at 10:42 AM, Ian Lepore wrote:

> On Mon, 2013-02-11 at 09:14 -0800, 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.)
>> 
> 
> I actually find it much easier to recompile the kernel than any of the
> other alternatives I've run into, but I understand that an end user
> would see it differently.  I also find that while I'm trying to be
> open-minded about fdt in general, I still find it much more cumbersome
> to work with than the old hints system.  The very fact that you need a
> special compiler to change the fdt data is part of that.
> 
> In general, the fdt data seems to be good at describing hardware
> relationships that are hard to express with simple hints, such as how
> pins that generate interrupts are mapped between various devices and
> interrupt controllers.  But it seems to be hard to use when the nature
> of the customizations are simple choices.

Indeed.

>> 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.
>> 
> 
> I whole-heartedly agree with that last sentence, but it's about a
> zillion miles from where our code is now.  I'm not even sure it's fully
> possible, it just seems like a nice generic ideal "I asked for a uart,
> so the uart driver should enable power, enable clocks, and assign pins
> to make that happen."  The problem crops up when "assign pins" has
> several sets of pins to choose from for a given device, and I know at
> least the Atmel SoCs do this a lot.

In Linux land, at least for Atmel, they have created pin groups that are switched together when things like the uarts are enabled. It looks to be pretty slick, but I haven't seen it in its final form.

We can do it mostly by default, with the special cases being handled specially.

>> 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.
>> 
>> 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.
>> 
> 
> I'll look into this, although when I was playing with it a couple weeks
> ago, I was having a hard time doing *anything* with loader.rc at all. 
> 
> That got me involved in trying to get the forth code running so that
> we'd have the full btx-loader goodness in the arm world with loader.conf
> files that we're all familiar with already.  That was going pretty well
> except for our kernels not having proper elf headers, and I started to
> sidetrack to fix that, and then $work happened and I haven't gotten back
> to any of it yet.

I hate it when $work happens...

Warner

> -- Ian
> 
>>>> 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.
> 
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"