Date: Sun, 10 Feb 2013 21:06:27 +1300 From: Andrew Turner <andrew@fubar.geek.nz> To: Warner Losh <imp@bsdimp.com> Cc: Tim Kientzle <tim@kientzle.com>, freebsd-arm@freebsd.org, Brett Wynkoop <wynkoop@wynn.com> Subject: Re: building RaspPi Images Message-ID: <20130210210627.128f7b4a@bender> In-Reply-To: <A187F857-D0A0-4331-8266-3DA8FD0E2ED1@bsdimp.com> References: <5116CB50.9080303@ceetonetechnology.com> <7757848F-45C6-4DEF-A4A2-5F900EB10A06@kientzle.com> <20130210012052.4d7e1a46@ivory.local> <58DCA6BE-8C06-4F69-81A2-A3582FBB5B12@kientzle.com> <20130210203222.6b51e505@bender> <A187F857-D0A0-4331-8266-3DA8FD0E2ED1@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Feb 2013 00:52:16 -0700 Warner Losh <imp@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130210210627.128f7b4a>