building RaspPi Images

[Ian Lepore]

On Mon, 2013-02-11 at 09:10 -0700, Warner Losh wrote:
> On Feb 11, 2013, at 9:01 AM, Ian Lepore wrote:
> 
> > On Sun, 2013-02-10 at 00:07 -0700, Warner Losh wrote:
> >> On Feb 10, 2013, at 12:03 AM, Tim Kientzle wrote:
> >> 
> >>> On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote:
> >>>> 
> >>>> I was thinking that we should be able to generate a generic image that
> >>>> will boot on both the Pi and the Bone.  Maybe a config file that
> >>>> includes the needed drivers for both boards.
> >>> 
> >>> I've thought about this and believe it is pretty routine,
> >>> though I've not had time to actually try implementing it.
> >>> 
> >>> This specific combination is simplified by the fact
> >>> that the boot bits are so different, so you can just
> >>> put them all on the same SD card image.
> >>> 
> >>> There are a few pieces you'll need to work through:
> >>> 1. An MSDOS partition with all the boot bits from both systems
> >>> 2. A kernel with all of the drivers for both systems
> >>> 3. ubldr will need to identify the board somehow
> >>> 4. ubldr will need to obtain the correct FDT
> >> 
> >> uboot is supposed to be providing the correct FDT. IF we aren't using it, we're doing FDT wrong and need to fix that.
> >> 
> >>> Except for #3, this should all be entirely routine.
> >>> 
> >>> For #4, the trick is to not compile any DTB into the
> >>> kernel.  Instead, the DTB is given to the kernel by
> >>> the boot bits:
> >>> 
> >>> * For RPi, this already happens:  the first-stage boot
> >>>    loads a DTB, ubldr uses "fdt addr" to access that DTB
> >>>    in a known location and then passes it to the kernel.
> >> 
> >> Doesn't the RPi's boot loader give our /boot/loader enough info to get this without the fdt addr command?
> >> 
> >>> * For Beaglebone, you can use loader.rc commands to load
> >>>   the proper DTB from the UFS partition.  I'm using the following
> >>>   on my BeagleBone right now:
> >>>        /boot/beaglebone.dtb
> >>>        /boot/loader.rc contains
> >>>            load /boot/kernel/kernel
> >>>            load -t dtb /boot/beaglebone.dtb
> >>>            autoboot
> >> 
> >> why isnt' the beagle board's boot loader passing it to /boot/loader?
> >> 
> >>> This should be an afternoon's work for someone who already
> >>> has a good understanding of FreeBSD boot processes.
> >> 
> >> The real solution here is to get the FDT plumbed through from the boards primary boot strap code into our code. Linux requires that this be passed in via like r2 for Linux to boot. We should make use of that too.
> >> 
> >> Warner
> > 
> > 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?
> 
> 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.

-- Ian