Date: Sun, 10 Feb 2013 00:52:16 -0700 From: Warner Losh <imp@bsdimp.com> To: Andrew Turner <andrew@fubar.geek.nz> Cc: Tim Kientzle <tim@kientzle.com>, freebsd-arm@freebsd.org, Brett Wynkoop <wynkoop@wynn.com> Subject: Re: building RaspPi Images Message-ID: <A187F857-D0A0-4331-8266-3DA8FD0E2ED1@bsdimp.com> In-Reply-To: <20130210203222.6b51e505@bender> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> On Feb 9, 2013, at 10:20 PM, Brett Wynkoop wrote: >>>=20 >>> 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. >>=20 >> I've thought about this and believe it is pretty routine, >> though I've not had time to actually try implementing it. >>=20 >> 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. >>=20 >> 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... > - 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... Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A187F857-D0A0-4331-8266-3DA8FD0E2ED1>