building RaspPi Images
Andrew Turner
andrew at fubar.geek.nz
Sun Feb 10 08:06:32 UTC 2013
On Sun, 10 Feb 2013 00:52:16 -0700
Warner Losh <imp at bsdimp.com> wrote:
>
> On Feb 10, 2013, at 12:32 AM, Andrew Turner wrote:
>
> > On Sat, 9 Feb 2013 23:03:38 -0800
> > Tim Kientzle <tim at kientzle.com> 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
> > 5. Update the kernel to allow it to be built for multiple boards.
> > You will need to at least fix:
> > - locore.S generates a fixed VA -> PA map, it's not too hard to fix
> > this, I've looked into it but don't have the time to get it into a
> > usable state.
>
> Aren't there also a number of VA/PA translations elsewhere that are
> also hard coded via various #defines...
Yes, some of these are safe as they are for devices we use before the
dynamic mapping is set up, e.g. for the uart.
>
> > - initarm calls a number of functions that have are implemented on a
> > per SoC family case.
>
> FDT can help us here. We can get the SoC from it.
>
> > - Update the IRQ mask/unmask/next irq functions to allow multiple
> > implementations and pick the correct one on boot.
> > - Ditto for DELAY, DMA, reset, etc functions.
>
> I started on this at one point...
>
> > I would suggest the first step is to get a kernel that can boot on
> > the BeagleBone and PandaBoard. As they both have Ti CPUs they are
> > similar enough we could skip some of the items in my list as they
> > are already using a common SoC specific code base.
>
> I've also been pushing this for different Atmel boards as well, but
> there isn't even FDT support for it just yet...
I'm planning on returning to FDT Atmel when EABI is in a usable state
with clang, real soon now(tm), along with other FDT work.
Andrew
More information about the freebsd-arm
mailing list