Re: [linuxdc-dev] cvs and kernel building

[M. R. B. <ma...@uw...>]

On Thu, 8 Feb 2001, Jeff Thompson wrote:

> I recently placed this as a comment to the cvs source being available on
> sourceforge but figured this would be a more appropriate place to put my
> questions.
> 
>  First a note about my setup
> 
> RedHat 6.2
> binutils-sh4-linux-010127-2.i386.rpm
> gcc-sh4-linux-2.97.001120-3.i386.rpm
> gdb-sh-linux-5.0.001127-2.i386.rpm
> 
> Please note that the gcc is actually -2.deb version, but alien increased
> the number
> when I converted it. I was unable to find the -1 version as listed in the
> HOWTO
> document.
>

First off, you will want to change the CFLAGS in arch/sh/Makefile that
specify -m4-nofpu to -m4.  The -m4-nofpu option actually targets the SH3
series (overriding target selection from `make config').  I've addressed
this to the LinuxSH-dev list.  Without this option set to -m4, many, many
things will break.
 
> 
> When I compile the firstkernel tarball's source I get the following error:
> 
> make[1]: Entering directory `/root/box/kernel/arch/sh/kernel'
> sh4-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/root/box/kernel/include -ml
> -m4-nofpu -c -o entry.o entry.S
> entry.S: Assembler messages:
> entry.S:375: Error: must be @(r0,...)
> entry.S:376: Error: must be @(r0,...)
> entry.S:377: Error: must be @(r0,...)
> entry.S:378: Error: must be @(r0,...)
> entry.S:379: Error: must be @(r0,...)
> entry.S:433: Error: must be @(r0,...)
> make[1]: *** [entry.o] Error 1
> make[1]: Leaving directory `/root/box/kernel/arch/sh/kernel'
> make: *** [_dir_arch/sh/kernel] Error 2
> 
> I assume that this is caused by the problems with different gcc versions
> as
> mentioned in the HOWTO document. Has anyone else got this going with this
> version of gcc from m17n.com?
>

This first error is due to the fact that the newer binutils (the ones
you're currently using) are case-insensitive when it comes to register
names.  arch/sh/kernel/entry.S uses macros (R0, SR) which violate this.
There is a fix in the latest LinuxSH kernel, as I write this I'm preparing
to merge changes from LinuxSH's kernel (2.4.1-final) into our slightly
dated LinuxDC kernel.
 
> I also retrieved the cvs source and attempted to compile. In this case I
> get a failure
> in the make dep:
> 
> make[4]: Leaving directory `/root/box/linux/net/bridge'
> make -C core fastdep
> make: Entering an unknown directory
> make: *** core: No such file or directory. Stop.
> make: Leaving an unknown directory
> make[3]: *** [_sfdep_core] Error 2
> make[3]: Leaving directory `/root/box/linux/net'
> make[2]: *** [fastdep] Error 2
> make[2]: Leaving directory `/root/box/linux/net'
> make[1]: *** [_sfdep_net] Error 2
> make[1]: Leaving directory `/root/box/linux'
> make: *** [dep-files] Error 2
> 

Did you remember to do `make ARCH=sh dep' instead of just `make dep'?
When cross-compiling, all make parameters must include ARCH=sh to build
correctly.

[...]
> So, the next question is, has anyone had any luck in building these
> sources? Any
> tips or thoughts are welcome!
> 

The current LinuxDC kernel cannot be built easily (unfortunately).

I haven't gotten around to finishing my own versions of Installation and
Tools HOWTOs, right now it's pretty much "glean from LinuxSH, adapt to
LinuxDC".  I have more time now to start streamlining the process.

> I'll be spending some time this weekend working on these problems and
> trying to get
> things going. I work for a OS level computer security company and have two
> other
> kernel developers who are going to be getting linux going on their systems
> (we want
> to get our security extensions on the dreamcast just for fun!), so
> hopefully we'll be
> able to make a few substantial contributions to the effort.
> 

That's sounds pretty cool.  What kind of security patches do you have?
I'm still debating adding LIDS into my LRP router...

I hope to have gdrom, PCI, maple input, and framebuffer up and running by
next week.  No, I'm not just leeching off of Marcus Comstedt's NetBSD
sources (well, maybe for GD-ROM and PCI ;), but I've been working on FB
and maple input (that conforms to Linux 2.4's Input Core) off and on. 
With Maple input, you'll be able to "hotplug" maple devices, and let the
proper handler (input core or generic maple) take over based on the
device.  More on this later. 

> Thanks for any help!
> 

Heh.  Tell all your kernel hacker friends about us :)

> Jeff
> 
> Jeff Thompson
> Software Evangelist and Visionary
> Senior Security Analyst
> Argus Systems Group, Inc.
> 

M. R.

P.S. BTW, it doesn't look like Rene's DC RTC patches ever made it into the
CVS (?).  I have my own patches, which I'm going to update soon, that has
DC RTC and some low-level PowerVR2DC interrupt handling.