d.stonier at gmail
Aug 11, 2009, 9:35 PM
Post #5 of 5
(1228 views)
Permalink
|
|
Re: newbie - building bootable image for ARM target on I686 host
[In reply to]
|
|
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 <wireless [at] tampabay>:
> Brenden Walker wrote:
>> On Fri, 07 Aug 2009 13:09:56 +0200 Karl Hiramoto <karl [at] hiramoto> wrote:
>>> Brenden Walker wrote:
>>>> I'm new to embedded linux, but been using Gentoo for a long time..
>> <snip>
>>>> 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. On 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. QEMU is the boot loader and you tell it
>>> 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=/dev/sda1 clock=pit"
>>>
>>>
>>> If your interested in the kernel details theres a general doc in
>>> <linux>/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, that 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. If 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 an 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
>
>
>
>
|
