[Aboriginal] Using filesystem images on real hardware
Matthew J Fletcher
amimjf at sky.com
Mon Jul 11 12:46:17 PDT 2011
On 11/07/11 14:51, Rob Landley wrote:
> On 07/10/2011 02:15 AM, Matthew J Fletcher wrote:
>> Hi,
>>
>> I've built various filesystem images (armv6l,i486) and run them in qemu
>> using the aboriginal build machinery just fine.
>
> Yay!
>
>> Presuming a given specific target board has linux port, e.g Chumby or
>> PandaBoard, i guess i just have to create a new target (settings file),
>
> All Aboriginal Linux needs is a new settings file, yes.
>
> What your _target_ is going to need is:
>
> 1) binutils+gcc support.
>
> 2) libc support (either in uClibc, or you'll need a sources/sections
> script to build glibc and changes to simple-cross-compiler.sh and
> native-compiler.sh to "build_section glibc" instead of "build_section
> uClibc". Note that glibc requires perl as a build prerequisite, which
> is why I added HOST_EXTRA, which is described in the top level "config"
> file.)
>
> 3) linux support.
>
> If your target is already supported by those four software packages,
> you're good. If it isn't, and you need to supply alternate versions of
> binutils/gcc/uClibc/linux. (There's
> USE_UNSTABLE=uClibc,gcc-core,binutils infrastructure for this, but I
> really need to update the documentation. Lemme know if you need to do
> that and I'll add a FAQ entry...)
>
>> make sure the gcc parameters are correct for soft/hard float and get a
>> kernel config file for settings like the following;
>
> Kernel config and uClibc config. Plus you need to set KARCH to what the
> kernel needs ARCH= set to, and so on.
>
>> CONFIG_CPU_V6=y
>> CONFIG_MMU=y
>> CONFIG_ARM_THUMB=y
>> CONFIG_AEABI=y
>> CONFIG_VFP=y
>
> I recently started to automate this, but it's still a bit ugly:
>
> 1) Put together your .config file like you want it.
> 2) run miniconfig.sh on it as described in the FAQ:
> http://landley.net/aboriginal/FAQ.html#dev_miniconfig
> 3) Use sources/toys/filter.py with the appropriate baseconfig as your
> first argument and your new miniconfig as the second. It'll spit out
> all the symbols in the second which weren't in the first.
>
> Then go through it and figure out what you actually _need_...
>
>> # Versatile board
>>
>> CONFIG_ARCH_VERSATILE_PB=y
>> CONFIG_PCI_LEGACY=y
>> CONFIG_SERIAL_NONSTANDARD=y
>> CONFIG_SERIAL_AMBA_PL011=y
>> CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
>> CONFIG_RTC_DRV_PL031=y
>> CONFIG_SCSI_SYM53C8XX_2=y
>> CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
>> CONFIG_SCSI_SYM53C8XX_MMIO=y
>
> Assuming your new thing is based on a versatile board, sure.
>
>> how did you find that just these config options need to be set, looking
>> at most linux kernel config files there are about 4000 lines in it.
>
> The FAQ explains miniconfig. Since even most of the miniconfig options
> were common between boards I split out the common options into
> "baseconfig" and the CONFIG_LINUX stuff gets appended to that, then fed
> into the kernel.
>
>> I guess most of those are defaults, do you just diff a default config file
>> against a board specific one and see whats different ? then make semi
>> intelligent guesses about if those changes are actually target specific
>> or just the personal preference of the guy who created the kernel config
>> for that board ?
>
> I work out the config I want, which is generally pretty minimal. Start
> with allnoconfig and switch on what you need. Record what you switched
> on. That's miniconfig. (The miniconfig.sh script just boils down an
> existing config into a miniconfig by removing everything that's at the
> allnoconfig default value or which the dependencies would set for you if
> you switch on the other symbols. I need to patch the kconfig C code to
> do this for me, the way I'm doing it now is really slow and works it out
> experimentally by removing each line and seeing which ones change there
> result and which ones don't.)
>
> Having done a bunch of boards, there's some commmon infrastructure like
> ext3 that they're all going to need, that's pretty much baseconfig. I
> got that by looking at the dozen or so miniconfigs I had at the time and
> factoring out the common symbols. It's really "what a kernel needs to
> run an aboriginal linux system image under qemu". A real hardware board
> running jffs2 or something would need totally different symbols.
>
> Rob
>
Rob, thanks for the help.
Ok so i start with the freescale 2.6.31 patched up sources with a
imx25_3stack_defconfig for the board.
So reading the FAQ i run 'make allnoconfig KCONFIG_ALLCONFIG=filename',
so i am guessing if filename is an input or an output ? well it does not
produce a file called 'filename', and the '.config' created is for a
x86_64 build which is my host.
So i presume 'filename' is an input, so i pass it the filename of my
defconfig. Humm, that created a '.config' file for x86_64 as well.
Ok, i will replace '.config' with my defconfig and try again. 'cp
imx25_3stack_defconfig .config', then do 'make allnoconfig
KCONFIG_ALLCONFIG=filename', humm its re-written my Arm defconfig to be
x86_64 again.
Not making much progress here. Whatever i do the 'make allnoconfig'
seems to make a x86_64 '.config' file.
regards
---
Matthew J Fletcher
amimjf(at)sky.com
www.amimjf.org
---
More information about the Aboriginal
mailing list