gc-linux-devel — Development-related discussion.

[Gc-linux-devel] Howto, please

[Billybob <bil...@ve...>]

This isn't related to the development of Linux for the GameCube, but it 
is related to the development of Linux for another Nintendo system ;)
To the point: I'm relatively new to doing any kind of kernel hacking, 
linux porting, etc... I know how to use Linux, and I can program most 
languages you can throw at me (i.e. C/C++), though.
So can anyone give me some hints or directions on how to begin porting 
Linux to an unsupported system? Since the target system is a nintendo 
system I figured asking for help here would be the best place.

Any help is greatly appreciated.

Thank you for your time.

[Gc-linux-devel] Re: Re: RTC driver

[JockyW <joc...@ho...>]

"Arthur Othieno" <a.o...@bl...> wrote in message
news:20040426230746.GA1966@mars...
> On Mon, Apr 26, 2004 at 11:41:12PM +0200, JockyW wrote:
> > I'm now building 2.6.5 and noticed that gamecubefb.c and fbmem.c need a
> > #define __powerpc__ in order to build the kernel. W/o these there is a
> > missing reference to fb_writel_real()
>
> Sounds like your setup (probably toolchain) might be up to some
> funkiness - I can't seem to reproduce that here.
>
Yes, you are absolutely right. I used the PPC gcc 3.3 cross-compiler for
Linux (by Wintermute). This has always worked fine for building
kernelversions 2.6.3 and 2.6.4.

I have now built a perfectly working 2.6.5 kernel directly on the cube :)
It only takes a bit longer ...

Thanks for your help!

JockyW

Re: [Gc-linux-devel] Re: RTC driver

[<a.o...@bl...>]

On Mon, Apr 26, 2004 at 11:41:12PM +0200, JockyW wrote:
> I'm now building 2.6.5 and noticed that gamecubefb.c and fbmem.c need a
> #define __powerpc__ in order to build the kernel. W/o these there is a
> missing reference to fb_writel_real()
 
Sounds like your setup (probably toolchain) might be up to some
funkiness - I can't seem to reproduce that here.

Taken from 2.6.5, wrapped for legibility:

include/linux/fb.h:554:#elif defined(__i386__) || defined(__alpha__) || \
			defined(__x86_64__) || defined(__hppa__) || \
			defined(__sh__) || defined(__powerpc__)

> Everything works as usual (also the RTC, thanks Torben!), except that the
> screen is very green and not very clear. It seems to me that the __powerpc__
> definitions that I added also have a negative impact :(

Sounds like you're crashing before the framebuffer console kicks in. You
could either enable the debug console to see the call trace (if any), or
start with the default config (`make gamecube_defconfig') and play the
fun game of elimination.

	Arthur

[Gc-linux-devel] Re: Re: RTC driver

[JockyW <joc...@ho...>]

"Michael Steil" <st...@in...> wrote in message
news:C69...@in......
> The RTC driver has been put into the CVS. Checkout the kernel from
> there to test it. :-)
>
>    Michael
>
Thanks Michael:)

I'm now building 2.6.5 and noticed that gamecubefb.c and fbmem.c need a
#define __powerpc__ in order to build the kernel. W/o these there is a
missing reference to fb_writel_real()

Everything works as usual (also the RTC, thanks Torben!), except that the
screen is very green and not very clear. It seems to me that the __powerpc__
definitions that I added also have a negative impact :(

PS: I still have an unanswered question related to a dvd driver which I
developed:
Do you know to what memory the virtual address 0xc2004048 is mapped? When I
convert it to a bus or phys address it doesn't seem to be a physical
address.

JockyW

[Gc-linux-devel] Re: Re: RTC driver

[JockyW <joc...@ho...>]

>
> NTP works OK, but a) you probably need a bigger sanity limit (like ten
> million), and b) you do need to get it closer than the start of the
> epoch.  What I do is to manually set the date to 1/1/04 in one of the
> init.d scripts before running ntpdate.
>
> Adam
>
I just solved that issue by starting ntpd with -g argument. Appr. 3 minutes
after ntpd is started time is synchronized.

Thx anyway for the alt solution

JockyW

Re: [Gc-linux-devel] Re: RTC driver

[Adam T. <ad...@io...>]

On Mon, 2004-04-26 at 13:39, JockyW wrote:
> I use NTP, but it doesn't work properly. I always get this:
> "Jan  1 01:03:32 cube ntpd[191]: time correction of 1083004124 seconds
> exceeds sanity limit (1000); set clock manually to the correct UTC time."
> 
> I'd be happy to test your RTC driver.

NTP works OK, but a) you probably need a bigger sanity limit (like ten
million), and b) you do need to get it closer than the start of the
epoch.  What I do is to manually set the date to 1/1/04 in one of the
init.d scripts before running ntpdate.

Adam

Re: [Gc-linux-devel] Re: RTC driver

[Michael S. <st...@in...>]

The RTC driver has been put into the CVS. Checkout the kernel from 
there to test it. :-)

   Michael

On Apr 26, 2004, at 8:39 PM, JockyW wrote:

>
> "Torben Nielsen" <tr...@bi...> wrote in message
> news:1082187695.1177.19.camel@hannibal...
>> I wrote a driver for the gamecube real time clock. It works fine for 
>> me,
>> so I wonder if it is possible to contribute the code to the project.
>> Or is everyone else just running NTP?
>>
>
> I'm interested!
>
> I use NTP, but it doesn't work properly. I always get this:
> "Jan  1 01:03:32 cube ntpd[191]: time correction of 1083004124 seconds
> exceeds sanity limit (1000); set clock manually to the correct UTC 
> time."
>
> I'd be happy to test your RTC driver.
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Gc-linux-devel mailing list
> Gc-...@li...
> https://lists.sourceforge.net/lists/listinfo/gc-linux-devel
>

[Gc-linux-devel] Re: RTC driver

[JockyW <joc...@ho...>]

"Torben Nielsen" <tr...@bi...> wrote in message
news:1082187695.1177.19.camel@hannibal...
> I wrote a driver for the gamecube real time clock. It works fine for me,
> so I wonder if it is possible to contribute the code to the project.
> Or is everyone else just running NTP?
>

I'm interested!

I use NTP, but it doesn't work properly. I always get this:
"Jan  1 01:03:32 cube ntpd[191]: time correction of 1083004124 seconds
exceeds sanity limit (1000); set clock manually to the correct UTC time."

I'd be happy to test your RTC driver.

[Gc-linux-devel] RTC driver

[Torben N. <tr...@bi...>]

I wrote a driver for the gamecube real time clock. It works fine for me,
so I wonder if it is possible to contribute the code to the project.
Or is everyone else just running NTP?

[Gc-linux-devel] Re: dvd kernelmodule: memory address problem

[JockyW <joc...@ho...>]

>
> Block device, you mean ;)
>
It'll become a block device. Since this is my first linux devicedriver, I
decided to start with a simple character devicedriver.

Meanwhile I got it to work with kmalloc. See my previous message nested deep
in this thread.
I would appreciate it if you can answer the question in that message (what
kind of address is 0xc200ba40, it doesn't map to physical memory)

Thanks again for your support :)

JockyW

Re: [Gc-linux-devel] dvd kernelmodule: memory address problem

[<a.o...@bl...>]

On Wed, Apr 14, 2004 at 06:44:55PM +0200, JockyW wrote:
> Thanks for your assistance Arthur,
> 
> My simple dvd characterdevice works quite well. I rewrote the linux IRQ2
> handler to handle all dvd irqs (not just the cover int).

Block device, you mean ;)

> But now I stumbled on a memory problem. My devicedriver uses a read buffer
> which is a 2048 bytes static char array. When I print the address, it sits
> on 0xC200EB24. That address doesn't work when I pass it to the DMA Memory
> Address Register. It is a strange address, because in "yagcd"
> http://www.gc-linux.org/docs/yagcd/chap4.html#sec4 it is written that
> uncached logical ram addresses run from 0xc0000000-0xc17fffff
> 
> What kind of address translation should I apply to get the dma to work?

You want to use memory allocated from a dma pool for that instead.

Create one with:

struct dma_pool *dma_pool_create(const char *name, struct device *dev,
			size_t size, size_t align, size_t alloc);

Allocate memory from it with:

void *dma_pool_alloc(struct dma_pool *pool, int gfp_flags,
			dma_addr_t *dma_handle);

Free alloc'd memory with dma_pool_free(), destroy the pool with
dma_pool_destroy().

See drivers/base/dmapool.c and Documentation/DMA-API.txt for
the gory details.

	Arthur

[Gc-linux-devel] Re: Re: dvd kernelmodule: memory address problem

[JockyW <joc...@ho...>]

Problem finally solved by allocating buffer memory with kmalloc
Like this: kmalloc (BUF_DISC, GFP_DMA);
The flag indicates that the allocated memory can be used in DMA transfers.
My original method, allocating a static char array, definitely doesn't work.
The virtual address 0xC200EB40 is not associated or cannot be mapped to
physical memory.

I still have no idea with what other memory it is associated. So if someone
can clear me up I would feel even more relieved.

[Gc-linux-devel] Re: Re: dvd kernelmodule: memory address problem

[JockyW <joc...@ho...>]

"Groepaz" <gr...@gm...> wrote in message
news:200...@gm......
>
> err? *dmareg=((address&~0xc0000000)>>5); ?

No, it is more like this: *dmareg=(address & 0x3FFFFE0);

But this wont work since 'address' is for example 0xC20048E0, which is not a
physical (0x00000000-0x017fffff) nor a logical address
(0x80000000-0x817fffff or 0xC0000000-0xC17fffff).

In my opinion 'address' must first be remapped to a logical address. I still
don't know how.

Re: [Gc-linux-devel] Re: dvd kernelmodule: memory address problem

[Groepaz <gr...@gm...>]

On Thursday 15 April 2004 17:27, JockyW wrote:
> Of course i have read that :) I didn't write it but I align the address
> before i pass it to the DMA address reg (same for length).
>
> Problem is that the DMA regs take only 26 bits (b0-b25) with b0-b4 all
> zero. My address is 32 bits so should I simply strip 6 bits off? I have the
> feeling that the address has to be remapped to some kind of bus address.
> But I have no idea how.

err? *dmareg=((address&~0xc0000000)>>5); ?

gpz

[Gc-linux-devel] Re: dvd kernelmodule: memory address problem

[JockyW <joc...@ho...>]

Of course i have read that :) I didn't write it but I align the address
before i pass it to the DMA address reg (same for length).

Problem is that the DMA regs take only 26 bits (b0-b25) with b0-b4 all zero.
My address is 32 bits so should I simply strip 6 bits off? I have the
feeling that the address has to be remapped to some kind of bus address. But
I have no idea how.

>
> for a start, make sure the address you pass to the dma registers is 32
byte
> aligned (didnt i write it somewhere? :=P)
>
> gpz
>

Re: [Gc-linux-devel] dvd kernelmodule: memory address problem

[Groepaz <gr...@gm...>]

On Wednesday 14 April 2004 18:44, JockyW wrote:
> Thanks for your assistance Arthur,
>
> My simple dvd characterdevice works quite well. I rewrote the linux IRQ2
> handler to handle all dvd irqs (not just the cover int).
>
> But now I stumbled on a memory problem. My devicedriver uses a read buffer
> which is a 2048 bytes static char array. When I print the address, it sits
> on 0xC200EB24. That address doesn't work when I pass it to the DMA Memory
> Address Register. It is a strange address, because in "yagcd"
> http://www.gc-linux.org/docs/yagcd/chap4.html#sec4 it is written that
> uncached logical ram addresses run from 0xc0000000-0xc17fffff
>
> What kind of address translation should I apply to get the dma to work?

for a start, make sure the address you pass to the dma registers is 32 byte
aligned (didnt i write it somewhere? :=P)

gpz

[Gc-linux-devel] dvd kernelmodule: memory address problem

[JockyW <joc...@ho...>]

Thanks for your assistance Arthur,

My simple dvd characterdevice works quite well. I rewrote the linux IRQ2
handler to handle all dvd irqs (not just the cover int).

But now I stumbled on a memory problem. My devicedriver uses a read buffer
which is a 2048 bytes static char array. When I print the address, it sits
on 0xC200EB24. That address doesn't work when I pass it to the DMA Memory
Address Register. It is a strange address, because in "yagcd"
http://www.gc-linux.org/docs/yagcd/chap4.html#sec4 it is written that
uncached logical ram addresses run from 0xc0000000-0xc17fffff

What kind of address translation should I apply to get the dma to work?


"Arthur Othieno" <a.o...@bl...> wrote in message
news:20040410170241.GA29363@mars...
> On Sat, Apr 10, 2004 at 04:59:51PM +0200, JockyW wrote:
> >
> > Thanks for your reply, but fttb it doesn't really help me.
> >
> > I have tried with this Makefile:
> >     obj-m := gcdvd.o
> >     module-objs := gcdvd.o cache.o
> >
> > But unfortunately cache.o isn't linked. After insmod gcdvd.o I get a
unknown
> > symbol, tho it is defined in cache.o
>
> s/module-objs/gcdvd-objs/
>
> > A bit strange is that insmod gcdvd.ko doesn't work at all because of a
bad
> > format or so. Only insmod gcdvd.o is accepted.
>
> You'll need module-init-tools for that. Grab them from
> http://kernel.org/pub/linux/utils/kernel/module-init-tools/
>
> See also http://lwn.net/Articles/22197/
>
> > As alternative to above Makefile I can take:
> > TARGET  := gcdvd
> > WARN    := -W -Wall -Wstrict-prototypes -Wmissing-prototypes
> > INCLUDE := -I/usr/src/linux/include
> > CFLAGS  := -c -O2 -DMODULE -D__KERNEL__ -DKBUILD_MODNAME="${TARGET}"
${WARN}
> > ${INCLUDE}
> > CC      := gcc-3.0
> >
> > ${TARGET}.o: ${TARGET}.c
> > cache.o: cache.S
> >
> > .PHONY: clean
> >
> > clean:
> >  rm -rf ${TARGET}.ko
> >  rm -rf ${TARGET}.o
> >
> > But there is again the problem that I don't know how to extend it such
that
> > it also links cache.o
> >
> > Any help is appreciated!
>
> See http://lwn.net/Articles/21823/ for how to properly compile external
> modules.
>
> Arthur
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: [Gc-linux-devel] I need a gc-linux hardware shopping list

[Groepaz <gr...@gm...>]

On Tuesday 13 April 2004 20:00, styroteqe wrote:
> What exactly is the "action replay" boot method?

in a nutshell, you create action replay codes that
patch the existing routines in the action replay
code itself to load a certain file from memory
card and execute it. search for the "ipl alpha test" or
something thread in dextrose.com forums.

gpz

Re: [Gc-linux-devel] I need a gc-linux hardware shopping list

[Groepaz <gr...@gm...>]

On Monday 12 April 2004 20:51, Michael Steil wrote:

> > It'd be nice if the source were available, but even the dynamically
> > linked version works for me, which is a little surprising given how
> > ancient the libraries on the box I'm serving it from are.
>
> Costis fears that the source will be abused for the creation of
> programs that support piracy. I can understand that.

costis is just a control freak, nothing more nothing less :=P there
really is no reason to not release source, other than wanting to 
keep it to yourself (which is everyones fair right ofcourse, i'm not
a big friend of releasing source either, for several reasons). they
are already pirating games, and they are already cheating pso -
releasing the code wouldnt change anything. (and like someone
said before, even a medioucre skilled hacker can reverse the crap
he'd need from the released exe file - even if he'd need to bootstrap
his own stuff using the already encoded packets. however this is neither
needed to pirate stuff nor to cheat pso. pirate tools just use the
existing loader binaries, and pso can be cheated more easily by
editing save games.).

whatever, my offer to supply our own stuff to someone who is skilled
in both networking and gamecube coding so he can develop it into a
really useable application still stands.

oh well,

gpz

Re: [Gc-linux-devel] I need a gc-linux hardware shopping list

[styroteqe <sty...@ya...>]

What exactly is the "action replay" boot method?

--- Alexandre Boeglin <al...@bo...> wrote:
> Selon Steven Looman <st...@kr...>: 
>  
> > There already was a psoloadv1.1 port which also
> works, and a few 
> days 
> > ago psoloadv2.0 for linux was (finally) released. 
>  
> Unfortunately, i feel that psoload2.0 has one of the
> worst network 
> code ever : it chooses the network interface it'll
> use in a really 
> strange and unefficient way, that makes it
> completelly unusable if 
> you've got more than one network interface. I
> personally used it just 
> 5 minutes, and switched back to psoload1.1 until the
> Action Replay 
> bootloader is a stable solution (psoload1.1 has the
> same problems, but 
> they are a little less present, and doesn't makes me
> unable to use 
> it). 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
> _______________________________________________
> Gc-linux-devel mailing list
> Gc-...@li...
>
https://lists.sourceforge.net/lists/listinfo/gc-linux-devel



	
		
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

Re: [Gc-linux-devel] I need a gc-linux hardware shopping list

[Alexandre B. <al...@bo...>]

Selon Steven Looman <st...@kr...>:=20
=20
> There already was a psoloadv1.1 port which also works, and a few=20
days=20
> ago psoloadv2.0 for linux was (finally) released.=20
=20
Unfortunately, i feel that psoload2.0 has one of the worst network=20
code ever : it chooses the network interface it'll use in a really=20
strange and unefficient way, that makes it completelly unusable if=20
you've got more than one network interface. I personally used it just=20
5 minutes, and switched back to psoload1.1 until the Action Replay=20
bootloader is a stable solution (psoload1.1 has the same problems, but=20
they are a little less present, and doesn't makes me unable to use=20
it).=20

Re: [Gc-linux-devel] I need a gc-linux hardware shopping list

[Adam T. <ad...@io...>]

On Tue, 2004-04-13 at 01:58, Steven Looman wrote:
> Some reverse engineering could also be done on the programs and the sent packets.

Yeah, I *could* sit down with tcpdump or ethereal and just watch what's
happening, but I don't care enough to spend the time to do that. 

> I don't know why Costis fears piracy; with the thing he released it is already possible, I don't see how an open source solution would change this. Online cheating (in PSO) is also an argument I've heard but this is already happening, afaik.

I suspect that the average pirate is *more* likely to sit down and do a
traffic analysis to reverse-engineer the protocol than I am, anyway.

I tend to believe that it's the initial GC loader that's the tricky 
bit.  Presumably the protocol looks something like this:

(If DHCP is enabled, DHCP broadcast for GC to get IP address)
GC issues DNS request to server learned by DHCP or coded in network
parms to get the IP address of an appropriate host (we know these names,
of course; PSOload has a small DNS server to return the patch host
rather than the real one, but you can put the records in a zone file on
any old DNS server and it works fine)
GC contacts the IP address it just learned on UDP/9002 or something
(codeable in PSOload switches) and sends some magic set of packets
requesting patch <-- this is the part you'd have to reverse-engineer
Host sends "patch" (i.e. Linux kernel) appended or prepended to loader
stub, so that you overwrite memory with the Linux kernel and overlay
wherever the instruction pointer goes after receiving the patch with a
jump to the beginning of the kernel.  <-- this is the tricky bit, since
the loader stub probably has to do some work to fake out the GC and make
it believe that it is a legitimate patch.  I have no idea what that
entails.

Adam

Re: [Gc-linux-devel] I need a gc-linux hardware shopping list

[Steven L. <st...@kr...>]

You could dump some traffic with a traffic dumper and create a program that sends the same packets, which has been done before (but in a bad way). This would give you an opensource solution, but the packets that are sent are still "closed source".

Some reverse engineering could also be done on the programs and the sent packets.

I don't know why Costis fears piracy; with the thing he released it is already possible, I don't see how an open source solution would change this. Online cheating (in PSO) is also an argument I've heard but this is already happening, afaik.

Steven (Steve_-)

On Mon, Apr 12, 2004 at 08:51:44PM +0200, Michael Steil wrote:
> On Apr 12, 2004, at 4:27 PM, Adam Thornton wrote:
> >On Mon, 2004-04-12 at 07:18, Steven Looman wrote:
> >>It's possible to drive everything from a linux box for some time now. 
> >>There already was a psoloadv1.1 port which also works, and a few days 
> >>ago psoloadv2.0 for linux was (finally) released.
> >It'd be nice if the source were available, but even the dynamically
> >linked version works for me, which is a little surprising given how
> >ancient the libraries on the box I'm serving it from are.
> 
> Costis fears that the source will be abused for the creation of 
> programs that support piracy. I can understand that.
> 
>   Michael
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Gc-linux-devel mailing list
> Gc-...@li...
> https://lists.sourceforge.net/lists/listinfo/gc-linux-devel
> 

Re: [Gc-linux-devel] I need a gc-linux hardware shopping list

[Michael S. <st...@in...>]

On Apr 12, 2004, at 4:27 PM, Adam Thornton wrote:
> On Mon, 2004-04-12 at 07:18, Steven Looman wrote:
>> It's possible to drive everything from a linux box for some time now. 
>> There already was a psoloadv1.1 port which also works, and a few days 
>> ago psoloadv2.0 for linux was (finally) released.
> It'd be nice if the source were available, but even the dynamically
> linked version works for me, which is a little surprising given how
> ancient the libraries on the box I'm serving it from are.

Costis fears that the source will be abused for the creation of 
programs that support piracy. I can understand that.

   Michael

Re: [Gc-linux-devel] I need a gc-linux hardware shopping list

[Adam T. <ad...@io...>]

On Mon, 2004-04-12 at 07:18, Steven Looman wrote:
> It's possible to drive everything from a linux box for some time now. There already was a psoloadv1.1 port which also works, and a few days ago psoloadv2.0 for linux was (finally) released.

Cool.

It'd be nice if the source were available, but even the dynamically
linked version works for me, which is a little surprising given how
ancient the libraries on the box I'm serving it from are.

Adam