Linux on the Nintendo GameCube and Wii

On Fri, Jul 16, 2004 at 05:56:55PM -0500, Mike Goggin wrote:
> I'd like to be able to build a kernel that will boot on the GC, but I'm 
> not sure where to start. I know I need kernel source, but what version 
> works with the patches in CVS?
 
All versions from 2.6.1 - 2.6.7

> About CVS, how do you apply the patches? They aren't like conventional 
> patches that I'm used to (ie-patch -p0 < patch.diff).
> 
> Any information would be greatly appreciated.

One of two ways (asumming you've unpacked a vanilla kernel):

1) Using GNU diff-style patches. These are on the project download page.
2) Checking out either a tagged release or HEAD from CVS, and copying
   that over your vanilla tree. Something like:

   cvs -d:pserver:anoymous@... co -r linux-2_6_N linux
   cp -r linux/* linux-2.6.N

   Where N could be 1-7, depending on what kernel version you're working
   with.  To check out a snapshot of the latest stuffi (HEAD), drop the
   -r option entirely.

	Arthur

Cool, thanks. Now, one more question...

I downloaded the 2.6.7 source, and got it patched to support the GC. 
make vmlinux compiles fine. But make zImage.initrd gives me the 
following error:

[tosk@... ~/linux-2.6.7]$ make zImage.initrd
make[1]: `arch/ppc/kernel/asm-offsets.s' is up to date.
  CHK     include/linux/compile.h
  SKIPPED include/linux/compile.h
  AS      arch/ppc/boot/simple/head.o
  AS      arch/ppc/boot/simple/relocate.o
  CC      arch/ppc/boot/simple/misc-embedded.o
arch/ppc/boot/simple/misc-embedded.c: In function `load_kernel':
arch/ppc/boot/simple/misc-embedded.c:80: warning: unused variable `ch'
arch/ppc/boot/simple/misc-embedded.c:81: warning: unused variable `timer'
  CC      arch/ppc/boot/simple/embed_config.o
arch/ppc/boot/simple/embed_config.c:45: warning: `def_enet_addr' defined 
but not used
objcopy -O elf32-powerpc \
        --add-section=.ramdisk=arch/ppc/boot/images/ramdisk.image.gz \
        --set-section-flags=.ramdisk=contents,alloc,load,readonly,data \
        --add-section=.image=arch/ppc/boot/images/vmlinux.gz \
        --set-section-flags=.image=contents,alloc,load,readonly,data \
        arch/ppc/boot/simple/dummy.o arch/ppc/boot/simple/image.o
ld -T /home/tosk/linux-2.6.7/arch/ppc/boot/ld.script -Ttext 0x00800000 
-Bstatic
-o arch/ppc/boot/simple/zvmlinux.initrd arch/ppc/boot/simple/head.o 
arch/ppc/boot/simple/relocate.o arch/ppc/boot/simple/misc-embedded.o 
arch/ppc/boot/simple/embed_config.o arch/ppc/boot/simple/image.o 
arch/ppc/boot/common/lib.a arch/ppc/boot/lib/lib.a
objcopy -O elf32-powerpc arch/ppc/boot/simple/zvmlinux.initrd 
arch/ppc/boot/simple/zvmlinux.initrd --change-addresses=-0x80000000 -R 
.comment -R .stab \
        -R .stabstr -R .sysmap
objcopy: --change-addresses: bad number: -0x80000000
make[2]: *** [arch/ppc/boot/simple/zvmlinux.initrd] Error 1
make[1]: *** [simple] Error 2
make: *** [zImage.initrd] Error 2

Did I do something wrong?

- Mike Goggin

Arthur Othieno wrote:

>On Fri, Jul 16, 2004 at 05:56:55PM -0500, Mike Goggin wrote:
>  
>
>>I'd like to be able to build a kernel that will boot on the GC, but I'm 
>>not sure where to start. I know I need kernel source, but what version 
>>works with the patches in CVS?
>>    
>>
> 
>All versions from 2.6.1 - 2.6.7
>
>  
>
>>About CVS, how do you apply the patches? They aren't like conventional 
>>patches that I'm used to (ie-patch -p0 < patch.diff).
>>
>>Any information would be greatly appreciated.
>>    
>>
>
>One of two ways (asumming you've unpacked a vanilla kernel):
>
>1) Using GNU diff-style patches. These are on the project download page.
>2) Checking out either a tagged release or HEAD from CVS, and copying
>   that over your vanilla tree. Something like:
>
>   cvs -d:pserver:anoymous@... co -r linux-2_6_N linux
>   cp -r linux/* linux-2.6.N
>
>   Where N could be 1-7, depending on what kernel version you're working
>   with.  To check out a snapshot of the latest stuffi (HEAD), drop the
>   -r option entirely.
>
>	Arthur
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by BEA Weblogic Workshop
>FREE Java Enterprise J2EE developer tools!
>Get your free copy of BEA WebLogic Workshop 8.1 today.
>http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
>_______________________________________________
>Gc-linux-devel mailing list
>Gc-linux-devel@...
>https://lists.sourceforge.net/lists/listinfo/gc-linux-devel
>
>  
>

On Sat, Jul 17, 2004 at 10:36:40PM -0500, Mike Goggin wrote:
> I downloaded the 2.6.7 source, and got it patched to support the GC. 
> make vmlinux compiles fine. But make zImage.initrd gives me the 
> following error:
> 
> [tosk@... ~/linux-2.6.7]$ make zImage.initrd
> make[1]: `arch/ppc/kernel/asm-offsets.s' is up to date.
>  CHK     include/linux/compile.h
>  SKIPPED include/linux/compile.h
>  AS      arch/ppc/boot/simple/head.o
>  AS      arch/ppc/boot/simple/relocate.o
>  CC      arch/ppc/boot/simple/misc-embedded.o
> arch/ppc/boot/simple/misc-embedded.c: In function `load_kernel':
> arch/ppc/boot/simple/misc-embedded.c:80: warning: unused variable `ch'
> arch/ppc/boot/simple/misc-embedded.c:81: warning: unused variable `timer'
>  CC      arch/ppc/boot/simple/embed_config.o
> arch/ppc/boot/simple/embed_config.c:45: warning: `def_enet_addr' defined 
> but not used
> objcopy -O elf32-powerpc \
>        --add-section=.ramdisk=arch/ppc/boot/images/ramdisk.image.gz \
>        --set-section-flags=.ramdisk=contents,alloc,load,readonly,data \
>        --add-section=.image=arch/ppc/boot/images/vmlinux.gz \
>        --set-section-flags=.image=contents,alloc,load,readonly,data \
>        arch/ppc/boot/simple/dummy.o arch/ppc/boot/simple/image.o
> ld -T /home/tosk/linux-2.6.7/arch/ppc/boot/ld.script -Ttext 0x00800000 
> -Bstatic
> -o arch/ppc/boot/simple/zvmlinux.initrd arch/ppc/boot/simple/head.o 
> arch/ppc/boot/simple/relocate.o arch/ppc/boot/simple/misc-embedded.o 
> arch/ppc/boot/simple/embed_config.o arch/ppc/boot/simple/image.o 
> arch/ppc/boot/common/lib.a arch/ppc/boot/lib/lib.a
> objcopy -O elf32-powerpc arch/ppc/boot/simple/zvmlinux.initrd 
> arch/ppc/boot/simple/zvmlinux.initrd --change-addresses=-0x80000000 -R 
> .comment -R .stab \
>        -R .stabstr -R .sysmap
> objcopy: --change-addresses: bad number: -0x80000000
> make[2]: *** [arch/ppc/boot/simple/zvmlinux.initrd] Error 1
> make[1]: *** [simple] Error 2
> make: *** [zImage.initrd] Error 2
> 
> Did I do something wrong?
 
No. The -0x80000000 is not a valid incremental value for --change-addresses.
Good catch. Funny how this doesn't barf on making zImage; the same funkiness
appears there as well.

Looking at the build output, I assume that you're building on a PPC host?
What version of binutils (objcopy --version)? In any case, this patch,
hackish at best, should fix things. Please confirm.


Index: arch/ppc/boot/simple/Makefile
===================================================================
RCS file: /cvsroot/gc-linux/linux/arch/ppc/boot/simple/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- arch/ppc/boot/simple/Makefile	16 Jun 2004 17:30:42 -0000	1.6
+++ arch/ppc/boot/simple/Makefile	20 Jul 2004 23:16:25 -0000
@@ -113,6 +113,10 @@
   entrypoint-$(CONFIG_SPRUCE)		:= 0x00800000
         misc-$(CONFIG_SPRUCE)		+= misc-spruce.o
 
+      zimage-$(CONFIG_GAMECUBE)		:= zImage-DOL
+zimageinitrd-$(CONFIG_GAMECUBE)		:= zImage.initrd-DOL
+         end-$(CONFIG_GAMECUBE)		:= dol
+
 # SMP images should have a '.smp' suffix.
          end-$(CONFIG_SMP)             := $(end-y).smp
 
@@ -167,7 +171,7 @@
 		--set-section-flags=.image=contents,alloc,load,readonly,data \
 		$(obj)/dummy.o $(obj)/image.o
 	$(LD) $(LD_ARGS) -o $@ $(OBJS) $(obj)/image.o $(LIBS)
-	$(OBJCOPY) $(OBJCOPY_ARGS) $@ $@ --change-addresses=-0x80000000 -R .comment -R .stab \
+	$(OBJCOPY) $(OBJCOPY_ARGS) $@ $@ -R .comment -R .stab \
 		-R .stabstr -R .ramdisk -R .sysmap
 
 $(obj)/zvmlinux.initrd: $(OBJS) $(LIBS) $(srctree)/$(boot)/ld.script \
@@ -179,7 +183,7 @@
 		--set-section-flags=.image=contents,alloc,load,readonly,data \
 		$(obj)/dummy.o $(obj)/image.o
 	$(LD) $(LD_ARGS) -o $@ $(OBJS) $(obj)/image.o $(LIBS)
-	$(OBJCOPY) $(OBJCOPY_ARGS) $@ $@ --change-addresses=-0x80000000 -R .comment -R .stab \
+	$(OBJCOPY) $(OBJCOPY_ARGS) $@ $@ -R .comment -R .stab \
 		-R .stabstr -R .sysmap
 
 # Sort-of dummy rules, that let us format the image we want.
@@ -218,3 +222,14 @@
 $(images)/zImage.initrd-PPLUS: $(obj)/zvmlinux.initrd $(MKPREP) $(MKBUGBOOT)
 	$(MKPREP) -pbp $(obj)/zvmlinux.initrd $(images)/zImage.initrd.$(end-y)
 	$(MKBUGBOOT) $(obj)/zvmlinux.initrd $(images)/zImage.initrd.bugboot
+
+#
+# FIXME Must generate actual .dol's. All these targets do ATM is to adjust
+# VMA/LMA addresses of all sections in the respective images so we can just
+# feed the result into `doltool'. Ick.
+#
+$(images)/zImage-DOL: $(obj)/zvmlinux
+	$(OBJCOPY) $(OBJCOPY_ARGS) $^ $^ --change-addresses=0x80000000
+
+$(images)/zImage.initrd-DOL: $(obj)/zvmlinux.initrd
+	$(OBJCOPY) $(OBJCOPY_ARGS) $^ $^ --change-addresses=0x80000000

Great. I'll confirm it as soon as I get YDL back on my Mac...or compile 
the kernel from Mac OS X. Either way, I'll let you know ASAP.

- Mike Goggin

On Jul 20, 2004, at 6:32 PM, Arthur Othieno wrote:

> On Sat, Jul 17, 2004 at 10:36:40PM -0500, Mike Goggin wrote:
>> I downloaded the 2.6.7 source, and got it patched to support the GC.
>> make vmlinux compiles fine. But make zImage.initrd gives me the
>> following error:
>>
>> [tosk@... ~/linux-2.6.7]$ make zImage.initrd
>> make[1]: `arch/ppc/kernel/asm-offsets.s' is up to date.
>>  CHK     include/linux/compile.h
>>  SKIPPED include/linux/compile.h
>>  AS      arch/ppc/boot/simple/head.o
>>  AS      arch/ppc/boot/simple/relocate.o
>>  CC      arch/ppc/boot/simple/misc-embedded.o
>> arch/ppc/boot/simple/misc-embedded.c: In function `load_kernel':
>> arch/ppc/boot/simple/misc-embedded.c:80: warning: unused variable `ch'
>> arch/ppc/boot/simple/misc-embedded.c:81: warning: unused variable 
>> `timer'
>>  CC      arch/ppc/boot/simple/embed_config.o
>> arch/ppc/boot/simple/embed_config.c:45: warning: `def_enet_addr' 
>> defined
>> but not used
>> objcopy -O elf32-powerpc \
>>        --add-section=.ramdisk=arch/ppc/boot/images/ramdisk.image.gz \
>>        --set-section-flags=.ramdisk=contents,alloc,load,readonly,data 
>> \
>>        --add-section=.image=arch/ppc/boot/images/vmlinux.gz \
>>        --set-section-flags=.image=contents,alloc,load,readonly,data \
>>        arch/ppc/boot/simple/dummy.o arch/ppc/boot/simple/image.o
>> ld -T /home/tosk/linux-2.6.7/arch/ppc/boot/ld.script -Ttext 0x00800000
>> -Bstatic
>> -o arch/ppc/boot/simple/zvmlinux.initrd arch/ppc/boot/simple/head.o
>> arch/ppc/boot/simple/relocate.o arch/ppc/boot/simple/misc-embedded.o
>> arch/ppc/boot/simple/embed_config.o arch/ppc/boot/simple/image.o
>> arch/ppc/boot/common/lib.a arch/ppc/boot/lib/lib.a
>> objcopy -O elf32-powerpc arch/ppc/boot/simple/zvmlinux.initrd
>> arch/ppc/boot/simple/zvmlinux.initrd --change-addresses=-0x80000000 -R
>> .comment -R .stab \
>>        -R .stabstr -R .sysmap
>> objcopy: --change-addresses: bad number: -0x80000000
>> make[2]: *** [arch/ppc/boot/simple/zvmlinux.initrd] Error 1
>> make[1]: *** [simple] Error 2
>> make: *** [zImage.initrd] Error 2
>>
>> Did I do something wrong?
>
> No. The -0x80000000 is not a valid incremental value for 
> --change-addresses.
> Good catch. Funny how this doesn't barf on making zImage; the same 
> funkiness
> appears there as well.
>
> Looking at the build output, I assume that you're building on a PPC 
> host?
> What version of binutils (objcopy --version)? In any case, this patch,
> hackish at best, should fix things. Please confirm.
>
>
> Index: arch/ppc/boot/simple/Makefile
> ===================================================================
> RCS file: /cvsroot/gc-linux/linux/arch/ppc/boot/simple/Makefile,v
> retrieving revision 1.6
> diff -u -r1.6 Makefile
> --- arch/ppc/boot/simple/Makefile	16 Jun 2004 17:30:42 -0000	1.6
> +++ arch/ppc/boot/simple/Makefile	20 Jul 2004 23:16:25 -0000
> @@ -113,6 +113,10 @@
>    entrypoint-$(CONFIG_SPRUCE)		:= 0x00800000
>          misc-$(CONFIG_SPRUCE)		+= misc-spruce.o
>
> +      zimage-$(CONFIG_GAMECUBE)		:= zImage-DOL
> +zimageinitrd-$(CONFIG_GAMECUBE)		:= zImage.initrd-DOL
> +         end-$(CONFIG_GAMECUBE)		:= dol
> +
>  # SMP images should have a '.smp' suffix.
>           end-$(CONFIG_SMP)             := $(end-y).smp
>
> @@ -167,7 +171,7 @@
>  		--set-section-flags=.image=contents,alloc,load,readonly,data \
>  		$(obj)/dummy.o $(obj)/image.o
>  	$(LD) $(LD_ARGS) -o $@ $(OBJS) $(obj)/image.o $(LIBS)
> -	$(OBJCOPY) $(OBJCOPY_ARGS) $@ $@ --change-addresses=-0x80000000 -R 
> .comment -R .stab \
> +	$(OBJCOPY) $(OBJCOPY_ARGS) $@ $@ -R .comment -R .stab \
>  		-R .stabstr -R .ramdisk -R .sysmap
>
>  $(obj)/zvmlinux.initrd: $(OBJS) $(LIBS) $(srctree)/$(boot)/ld.script \
> @@ -179,7 +183,7 @@
>  		--set-section-flags=.image=contents,alloc,load,readonly,data \
>  		$(obj)/dummy.o $(obj)/image.o
>  	$(LD) $(LD_ARGS) -o $@ $(OBJS) $(obj)/image.o $(LIBS)
> -	$(OBJCOPY) $(OBJCOPY_ARGS) $@ $@ --change-addresses=-0x80000000 -R 
> .comment -R .stab \
> +	$(OBJCOPY) $(OBJCOPY_ARGS) $@ $@ -R .comment -R .stab \
>  		-R .stabstr -R .sysmap
>
>  # Sort-of dummy rules, that let us format the image we want.
> @@ -218,3 +222,14 @@
>  $(images)/zImage.initrd-PPLUS: $(obj)/zvmlinux.initrd $(MKPREP) 
> $(MKBUGBOOT)
>  	$(MKPREP) -pbp $(obj)/zvmlinux.initrd 
> $(images)/zImage.initrd.$(end-y)
>  	$(MKBUGBOOT) $(obj)/zvmlinux.initrd $(images)/zImage.initrd.bugboot
> +
> +#
> +# FIXME Must generate actual .dol's. All these targets do ATM is to 
> adjust
> +# VMA/LMA addresses of all sections in the respective images so we 
> can just
> +# feed the result into `doltool'. Ick.
> +#
> +$(images)/zImage-DOL: $(obj)/zvmlinux
> +	$(OBJCOPY) $(OBJCOPY_ARGS) $^ $^ --change-addresses=0x80000000
> +
> +$(images)/zImage.initrd-DOL: $(obj)/zvmlinux.initrd
> +	$(OBJCOPY) $(OBJCOPY_ARGS) $^ $^ --change-addresses=0x80000000
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Gc-linux-devel mailing list
> Gc-linux-devel@...
> https://lists.sourceforge.net/lists/listinfo/gc-linux-devel
>

Indeed. The patch DID work. I now have a working kernel. I don't 
actually have a BBA for my GC yet, but I grabbed a GC emu off the net 
and it works well enough to load the kernel and let me know that it 
compiled properly.

Thanks for the help Arthur.

- Mike Goggin

PS-I never answered your questions, so: Yes, I built it on a PPC host 
(eMac 1GHz, 512MB RAM); and I have no clue what version of binutils I 
was using. It was whatever version came with Yellow Dog Linux 3.0.1. 
Though, after applying the patch, the kernel was built using Gentoo 
Linux (2.6.1-benh1). If you'd still like to know, I can grab the 
bintuils version for you for Gentoo.

On Jul 20, 2004, at 6:32 PM, Arthur Othieno wrote:

> No. The -0x80000000 is not a valid incremental value for 
> --change-addresses.
> Good catch. Funny how this doesn't barf on making zImage; the same 
> funkiness
> appears there as well.
>
> Looking at the build output, I assume that you're building on a PPC 
> host?
> What version of binutils (objcopy --version)? In any case, this patch,
> hackish at best, should fix things. Please confirm.

root@... wrote:
> I ordered a Max Drive Pro - Datel took the money of me, and they havent
> even finished making it yet. :-/
> As soon as I get it, I'll be able to tell you about it. But until then, I
> cant.

> Course, if the stuff with Origa stuff comes to fruition before datel
> finish maxdrive pro, then I'll cancel the order and get my cash back :)

I didn't quite get this one I'm afraid. What "Origa" stuff?

Is there anything else to boot over the network without pressing 10000 
buttons on the controller (Which is the reason why I would by one of 
these Max Drive Pro units)?

kind regards -ph-

On Thursday 15 July 2004 11:14, Philip Lawatsch wrote:
> root@... wrote:
> > I ordered a Max Drive Pro - Datel took the money of me, and they havent
> > even finished making it yet. :-/
> > As soon as I get it, I'll be able to tell you about it. But until then, I
> > cant.
> >
> > Course, if the stuff with Origa stuff comes to fruition before datel
> > finish maxdrive pro, then I'll cancel the order and get my cash back :)
>
> I didn't quite get this one I'm afraid. What "Origa" stuff?
>
> Is there anything else to boot over the network without pressing 10000
> buttons on the controller (Which is the reason why I would by one of
> these Max Drive Pro units)?

origa is a spanish guy who has appearently made a working modchip.

btw if you use a AR loader, exactly one button press and one open/close
of the lid is needed :=P

gpz

> origa is a spanish guy who has appearently made a working modchip.
>
> btw if you use a AR loader, exactly one button press and one open/close
> of the lid is needed :=P
>
> gpz

That seems to be very interesting. Do you know where can I find him (website 
or e-mail?

Qapla'

On Thursday 15 July 2004 15:43, Pezezin wrote:
> > origa is a spanish guy who has appearently made a working modchip.
> >
> > btw if you use a AR loader, exactly one button press and one open/close
> > of the lid is needed :=P
> >
> > gpz
>
> That seems to be very interesting. Do you know where can I find him
> (website or e-mail?

sorry i forgot....it was posted on some spanish webforum... i found the
link on either dextrose or gcdev or...some other page :=P maybe someone
else remembers :)

gpz

> > That seems to be very interesting. Do you know where can I find him
> > (website or e-mail?
>
> sorry i forgot....it was posted on some spanish webforum... i found the
> link on either dextrose or gcdev or...some other page :=P maybe someone
> else remembers :)
>
> gpz

Ok, thank you. I have found the forum, but they are not spanish, they are 
italian, and I don't understand italian very well :(

Anyway, what I have read is very interesting. Maybe we can burn a Linux ISO in 
a mini-DVD and boot with the modchip...

Qapla'

What about the Max Drive Pro developper version ! any of you tried it ?

bye
Fogel

On Wed, 14 Jul 2004 14:47:58 +0200, Philip Lawatsch <philip@...> wrote:
> Darrell Blake wrote:
> > I ordered one yesterday. When I receive it I'll post some info about it.
> 
> Any news about this device?
> 
> I'm considering to buy one of these too, if booting Linux works :)
> 
> kind regards -ph-
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit http://www.blackhat.com
> _______________________________________________
> Gc-linux-devel mailing list
> Gc-linux-devel@...
> https://lists.sourceforge.net/lists/listinfo/gc-linux-devel
>

> Darrell Blake wrote:
> > I ordered one yesterday. When I receive it I'll post some info about it.

FWIW, I ordered one near the end of June. Still no news whatsoever,
but I'm still confident they'll send it someday...

Cheers,
--Jonathan

Well as soon as you get one give us feedback :)
tnx
seeya
Fogel

On Thu, 15 Jul 2004 12:13:18 +0200, Jonathan Perret
<j-gclinux@...> wrote:
> > Darrell Blake wrote:
> > > I ordered one yesterday. When I receive it I'll post some info about it.
> 
> FWIW, I ordered one near the end of June. Still no news whatsoever,
> but I'm still confident they'll send it someday...
> 
> Cheers,
> --Jonathan
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> 
> 
> _______________________________________________
> Gc-linux-devel mailing list
> Gc-linux-devel@...
> https://lists.sourceforge.net/lists/listinfo/gc-linux-devel
>

> Well as soon as you get one give us feedback :)

Don't worry, I will. But I'm still waiting for them to be released.
Currently they stand at the 30th of July so it's not too long to wait...
providing they get released on time that is.

Darrell

On Thursday 08 July 2004 00:43, Mike Goggin wrote:
> This is probably a stupid question, but I'm going to ask anyway.
>
> How many colors does the fb driver allow you to display? 2? 8? 256? 65536?

2^24 ... well a little less, since some are out of gamut colors.

gpz