From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Mb5YO-0000CY-0X for garchives@archives.gentoo.org; Wed, 12 Aug 2009 04:35:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E4C1E038C; Wed, 12 Aug 2009 04:35:11 +0000 (UTC) Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by pigeon.gentoo.org (Postfix) with ESMTP id 1905FE038C for ; Wed, 12 Aug 2009 04:35:11 +0000 (UTC) Received: by gxk20 with SMTP id 20so13202095gxk.10 for ; Tue, 11 Aug 2009 21:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=9csGXu18tV40RuduNKkRehh3WcCPlFSPWLguxpeq9a0=; b=Lo83S+RQRy2WB7wDA2EVLBop3Spuhbmoz55YLbrt8pWw1bSCITYSnLwEpQJM9GwIfC iAnxS0bxM2Aza8g7UQi7t4v66I9qPf9dR95SKDOFRQEjeZhuImHVl838L73UQz9bHNM/ ELFqBedx1T6F8Iuu1CTkOw2McSG1H+/30iFqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=svCnDYK6hzTX0ZGRQd52N6ZPSZWF7s+/XHzimYTI47ehh0XMzYuAkqWalVq6HZ4pWJ wUS9cPiruhZqmcj5ZATZFwZWSINEGyxYpuhwJinCHgV25DGA8WRxgC5qtQBxMnxbtuSP /Jih0XWX8rFpf/+sn0zO+u1smwx9g02DQT7tQ= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-embedded@lists.gentoo.org Reply-to: gentoo-embedded@lists.gentoo.org MIME-Version: 1.0 Received: by 10.151.158.13 with SMTP id k13mr10075895ybo.110.1250051710421; Tue, 11 Aug 2009 21:35:10 -0700 (PDT) In-Reply-To: <4A7C64C6.5060807@tampabay.rr.com> References: <20090806161959.289b32fb@diablops.com> <4A7C0B84.90403@hiramoto.org> <20090807082431.31237052@diablops.com> <4A7C64C6.5060807@tampabay.rr.com> Date: Wed, 12 Aug 2009 13:35:08 +0900 Message-ID: <27dfa3d0908112135g164d216cp115cd649ba564cc7@mail.gmail.com> Subject: Re: [gentoo-embedded] newbie - building bootable image for ARM target on I686 host From: Daniel Stonier To: gentoo-embedded@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: cfa83997-942f-42cd-9854-1731c32e8a60 X-Archives-Hash: c33aa6637b84ebffc8a7953fd4003212 I think Brenden was also curious about what comes after the bootloader. So you get your bootloader figured out and the kernel, then what? You can point it at your crossdev root, but that in itself isn't bootable unless you do some work. It's just a cross-compilation tree. I ran into the same problem a year ago - didn't know what direction to head to make my own root filesystem layout. And most of the info you find on the internet doesn't really delve into it that much. There are a couple of directions that I've looked at: Build my own very minimal busybox based filesystem. Cross-compile packages in my crossdev and then copy them across to the real busybox-based root. This is great if you've only got very simple needs and only need a couple of packages. It worked for me for about a year, but now I'm starting to dump alot of control packages on the setup, its getting complicated. I need some sort of rule-based package manager. An alternative is to essentially create a gentoo bootable filesystem with baselayout and building up from there. I haven't tried this yet, but it shouldn't be too hard. Depending on size issues, you may want to strip alot of the unnecessary stuff (dev headers, docs etc). There are enough projects around that do this, you should find some info on it. Another alternative I looked at was OpenEmbedded, but at the time I was requiring something simple and that added more complexity to the management of it all than it subtracted. For complicated root filesystem builds though, I'm sure that ratio inverts and its starts being beneficial. One I want to look at in the future (seeing as we're using intel atoms now) is the moblin toolchain and image creator. Its not terribly developed yet, but the ideas behind it seem very appropriate for the developer wanting to build/customise their images. Regards, Daniel. PS - I'm still no expert in using all these tools, so dont take my advice as gospel! If someone has a better recommendation, I'm all ears too. 2009/8/8 wireless : > Brenden Walker wrote: >> On Fri, 07 Aug 2009 13:09:56 +0200 Karl Hiramoto wro= te: >>> Brenden Walker wrote: >>>> I'm new to embedded linux, but been using Gentoo for a long time.. >> >>>> time the plan was to use QEMU to demonstrate the basic process and >>>> for use in developing our application, so a disk image suitable for >>>> QEMU is what I'm hoping for. >>> The concept of bootable disk doesn't really exist. =C2=A0On most ARM HW >>> i've worked with the way the boot process works is you have a boot >>> loader (redboot, uboot, etc) that loads the kernel, then the kernel >>> paramaters tell it how to mount the root FS. >>> >>> QEMU works kinda the same. =C2=A0QEMU is the boot loader and you tell i= t >>> the kernel image name, then pass the kernel args to mount the root >>> for example: >>> >>> qemu-system-arm -M versatilepb -hda sda.img -kernel zImage -append >>> "root=3D/dev/sda1 clock=3Dpit" >>> >>> >>> If your interested in the kernel details theres a general doc in >>> /Documentation/arm/Booting >>> >>> >>> I have an old (kernel 2.6.19) qemu image, based on one somebody on >>> this list posted a long time ago, =C2=A0that you can boot: >>> http://karl.hiramoto.org/embedded/qemu-arm.tar.lzma >> >> Thanks for the help, I think my main issues are what boot loader, how to= get it into an >>image and what to use to build the image. =C2=A0If I can get that figured= out, I've got a >>gentoo setup for building arm binaries... I could probably muddle through= the rest ;-). > > > I just read in the Linux Journal that there is an effort under way to > standardize how all(most) linux distro bootstrap the Kernel. It may > make =C2=A0an interesting read for you to research these new efforts. > > Whether you use a stock bootloader, one from a vendor, or hack your > own, it definately affects how you subsequent system will perform, > and what licenses are relevant to your project, so do your research > to ensure what you use is consistent with how you intend to use the > work-product..... > > > caveat emptor, > > > James > > > >