[Aboriginal] kernel build problem for m68k

[Rob Landley]

On 07/11/2011 01:06 PM, Matthew J Fletcher wrote:
> On 11/07/11 15:05, Rob Landley wrote:
>> On 07/10/2011 02:43 AM, Matthew J Fletcher wrote:
>>> Hi,
>>>
>>> Using aboriginal 1.0.2
>>>
>>> ----
>>> In file included from arch/m68k/kernel/dma.c:4:
>>> arch/m68k/kernel/dma_no.c: In function 'dma_sync_single_for_cpu':
>>> arch/m68k/kernel/dma_no.c:44: error: implicit declaration of function
>>> 'flush_dcache_range'
>>> ----
>>
>> That's either a 2.6.39 bug or my m68k config needs to change for 2.6.39.
>>
>>> I dont often look in the linux kernel arch stuff, but here goes..
>>>
>>> flush_dcache_range() is a #define in cacheflush_no.h, so it looks like
>>> <asm/cacheflush.h>  is not including cacheflush_no.h
>>>
>>> looking at arch/m68k/include/asm/cacheflush.h there is a big fat #ifdef
>>> __uClinux__ i guess thats not being fulfilled ?
>>
>> That should never have gone upstream into Linus's tree, uClinux is a
>> distro that focuses on nommu system development.  (M68000 processors are
>> obsolete, so most of the action these days is around a derivative called
>> "coldfire" that started life as a nommu system and is still mostly used
>> that way.)
> 
> Yea i realise m68k is obsolete, it was the arch that powered by first
> computer and what i first started doing embedded work on so i have a
> soft spot for it.

Understood.  I want to get Alpha working too, I just haven't had time...

>> So yeah, kernel bug.  But we need to fix it.
>>
>> If you can fix it to make it build, make a "-p1" style patch (like git
>> diff generates, if you have to create 'em yourself diff the "linux"
>> directories between a vanilla version and your modified version).  Put
>> the patch in the "sources/patches" directory with a "linux-*.patch"
>> style name, and then re-run the build.  It should pick it up
>> automatically.
> 
> I fixed a couple of other nommu related build issues, but it looks like
> m68k gas may be behind the times as well,...

I'm still using binutils 2.17 (because that's the last GPLv2 release and
I really don't want to open the can of worms that is GPLv3.)

> arch/m68k/kernel/entry_no.S: Assembler messages:
> arch/m68k/kernel/entry_no.S:47: Error: Unknown operator -- statement
> `save_all' ignored
> arch/m68k/kernel/entry_no.S:56: Error: Unknown operator -- statement
> `save_all' ignored

Sigh.  It build under 2.6.37.  I think it did under .38.  I'll have to
bisect and see where this was introduced...

(The m68k target did at one point work under aranym, I just have trouble
regression testing it without qemu support.  My automated tests always
list it as "fail" because it doesn't run...)

>> The FAQ has a long, drawn out explanation of the package cache if you
>> care.  It makes building lots of targets faster, doesn't do so much for
>> building just one target:
>>
>>    http://landley.net/aboriginal/FAQ.html#debug_source
>>
> 
> I brute force and ignorance it by using an SSD :-)

It's actually not just disk speed, on a sequential build the killer is
the extra CPU of re-extracting all those tarballs, plus the extra I/O
and page cache from faulting in lots of different copies of the same
files into memory.  Even if your system has enough memory you can build
out of ramfs (which my friend Mark has), it's a very noticeable
performance difference.  (And when building all targets in parallel with
FORK=1 it's _huge_, due to the different instances of the same cached
data thrashing the L2 cache...)

Rob