XenoGC fork

User avatar
liquitt
Posts: 1810
Joined: Thu Apr 01, 2010 5:43 am
Location: neverland

XenoGC fork

Post by liquitt » Wed Sep 28, 2011 5:13 am

I just opened a googlecode page for this. Let me know if you want into it etc.

http://code.google.com/p/xenogcfork/
please search before you ask - a lot has been discussed already!
(or use google with "site:gc-forever.com *term*")
http://is.gd/MDmZcr

we also have a wiki filled with knowledge
http://is.gd/dX58Rm
dantheman2865
Posts: 34
Joined: Sun Sep 04, 2011 3:24 pm
Location: Flint, MI, USA
Contact:

Re: XenoGC fork

Post by dantheman2865 » Wed Sep 28, 2011 12:12 pm

Thanks liquitt, could you add me please? <My username>@gmail.com. I would like to start by putting the code we received from The Author as-is into the repository. What is best practice for this sort of thing? Keep the original in the trunk (maybe even read-only) and then branch off individual projects?
User avatar
liquitt
Posts: 1810
Joined: Thu Apr 01, 2010 5:43 am
Location: neverland

Re: XenoGC fork

Post by liquitt » Wed Sep 28, 2011 12:24 pm

added you as a committer, so start committing ;)
please search before you ask - a lot has been discussed already!
(or use google with "site:gc-forever.com *term*")
http://is.gd/MDmZcr

we also have a wiki filled with knowledge
http://is.gd/dX58Rm
User avatar
emu_kidid
Site Admin
Posts: 4927
Joined: Mon Mar 29, 2010 10:06 am
Location: Australia
Contact:

Re: XenoGC fork

Post by emu_kidid » Wed Sep 28, 2011 3:53 pm

Some progress on making the shell boot a special file that it automatically finds on memory card:

Image

Image

Image


Just needs a bit of work to get it actually booting now but that'll have to wait until I'm at home with some free time again!
Attachments
Image0929-0116(CVBS).jpg
(17.3 KiB) Not downloaded yet
Image0929-0112(CVBS)(1).jpg
(8.19 KiB) Not downloaded yet
Image0929-0112(CVBS).jpg
(32.07 KiB) Not downloaded yet
Image
User avatar
emu_kidid
Site Admin
Posts: 4927
Joined: Mon Mar 29, 2010 10:06 am
Location: Australia
Contact:

Re: XenoGC fork

Post by emu_kidid » Thu Sep 29, 2011 3:35 pm

Got it all working, I've committed my changes too, see the change log for what I fixed.
Details will come tomorrow on what I did to get the file onto the memory card/etc.

Image

Image
Attachments
Image0930-0106(CVBS)(1).jpg
(14.11 KiB) Not downloaded yet
Image0930-0106(CVBS).jpg
(10.66 KiB) Not downloaded yet
Image
dantheman2865
Posts: 34
Joined: Sun Sep 04, 2011 3:24 pm
Location: Flint, MI, USA
Contact:

Re: XenoGC fork

Post by dantheman2865 » Thu Sep 29, 2011 3:58 pm

Awesome! I'll try to take a look through the code. Will the next version of Swiss support loading files to the memory card? ;)
User avatar
wii_HD
Posts: 263
Joined: Tue Mar 08, 2011 8:27 pm
Location: United KIngdom

Re: XenoGC fork

Post by wii_HD » Thu Sep 29, 2011 7:27 pm

PM emu_kidid
Playing - Super Mario Sunshine - DariusBurst CS - Hotline Miami 2 - Rpi2 Lakka - X360 BurnOut Paradise City
User avatar
infact
Posts: 346
Joined: Tue Mar 29, 2011 4:35 am
Location: Germany

Re: XenoGC fork

Post by infact » Thu Sep 29, 2011 8:31 pm

I created a Makefile for the XenoShell.
But with and without it, I have a problem:
When I compile with the same options as you, I get a slightly bigger file.
The text sections are bigger. See here: http://pastie.org/private/ev9yj9aomuovg2hofhzmgq
I used powerpc-eabi-gcc (devkitPPC release 24) 4.6.1 on Linux x86_64.
Just wanted to know which version you are using.

Also there is something wrong with the elf files, when I use elf2dol it says:
Warning: writable and executable segment 0
Error: TEXT segment 0 memory size (0x1578) does not equal file size (0xd18)
Doltool doesnt complain.

Besides these issues, it works just fine.
infact
Image Image
User avatar
liquitt
Posts: 1810
Joined: Thu Apr 01, 2010 5:43 am
Location: neverland

Re: XenoGC fork

Post by liquitt » Thu Sep 29, 2011 9:24 pm

and again, i like where this thread is going ;)
please search before you ask - a lot has been discussed already!
(or use google with "site:gc-forever.com *term*")
http://is.gd/MDmZcr

we also have a wiki filled with knowledge
http://is.gd/dX58Rm
User avatar
infact
Posts: 346
Joined: Tue Mar 29, 2011 4:35 am
Location: Germany

Re: XenoGC fork

Post by infact » Thu Sep 29, 2011 10:25 pm

one step ahead...
Image
infact
Image Image
User avatar
megalomaniac
Posts: 2480
Joined: Sun Aug 21, 2011 5:33 am
Location: Drunk in Texas
Contact:

Re: XenoGC fork

Post by megalomaniac » Fri Sep 30, 2011 4:24 am

infact wrote:I created a Makefile for the XenoShell.
But with and without it, I have a problem:
When I compile with the same options as you, I get a slightly bigger file.
The text sections are bigger. See here: http://pastie.org/private/ev9yj9aomuovg2hofhzmgq
I used powerpc-eabi-gcc (devkitPPC release 24) 4.6.1 on Linux x86_64.
Just wanted to know which version you are using.

Also there is something wrong with the elf files, when I use elf2dol it says:
Warning: writable and executable segment 0
Error: TEXT segment 0 memory size (0x1578) does not equal file size (0xd18)
Doltool doesnt complain.

Besides these issues, it works just fine.

compare your makefile with the posted r8 update
my bin size compiled same as original 3.3k
emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
>>> BadAssConsoles.com <<<

Image Image Image
User avatar
infact
Posts: 346
Joined: Tue Mar 29, 2011 4:35 am
Location: Germany

Re: XenoGC fork

Post by infact » Fri Sep 30, 2011 6:54 am

As said I got the bigger file on r4 with exact the same gcc command as emu_kidid used.
The r8 compiles fine and has the right size.
I tried your Makefile with the r4 for teh lulz and it is 4,5kb again. :P
So I think I fixed it with the r5 when I shut up the compiler warnings.
infact
Image Image
dantheman2865
Posts: 34
Joined: Sun Sep 04, 2011 3:24 pm
Location: Flint, MI, USA
Contact:

Re: XenoGC fork

Post by dantheman2865 » Fri Sep 30, 2011 4:55 pm

@emu_kidid, Thanks for doing the clean-up in r9.

I am really hoping to do the XenoFlash libogc port but I know it will be slow so if someone else would rather do it please go ahead.

Thanks!
dantheman2865
Posts: 34
Joined: Sun Sep 04, 2011 3:24 pm
Location: Flint, MI, USA
Contact:

Re: XenoGC fork

Post by dantheman2865 » Sun Oct 02, 2011 2:49 am

Guys, I am working on porting XenoFlash to libOGC and thankfully I am making some headway into understanding the code.

The main portion that had me tripped up was the DVD Debug functions because libOGC doesn't include many of those. I was midway through writing them from scratch out of YAGCD when I found almost all of them in the GCOS source. At this point, the only one that I haven't been able to figure out is DVD_CallFunc().

As Emu_Kidid stated very early on, the way this works is by getting the MN102 to do the flash updating on the ATMega8. The code to do that is in flashloader.S and gets loaded into the MN102 by CMD_InjectCustomDriveCode(). My understanding is that DVD_CallFunc() somehow triggers different subroutines in the MN102 based on which offset is used (See Lines 20-24 in r9), the only thing is that I don't exactly know how this is triggered. If DVD_WriteMemDword is writing to the MN102's memory, then do we need to change a value in that same memory to get it to jmp to the correct function?

Code: Select all

void DVD_CallFunc(u32 fnAddress) {
	DVD_WriteDriveMemDword(fnAddress, ???);
}

I suppose a stronger understanding of the assembly code would probably yield an answer; I'm sure that's where the answer lies. Can anyone lend some insight?

Once we get this figured out, it's really just a matter of porting some display things over to libOGC. Also, I hate committing half-finished code but I changed the directory structure around and started an libOGC Makefile in addition to starting to change over main.cpp, feel free to revert if this is sloppy.

Thanks, I hope this is helpful!
dantheman2865
Posts: 34
Joined: Sun Sep 04, 2011 3:24 pm
Location: Flint, MI, USA
Contact:

Re: XenoGC fork

Post by dantheman2865 » Sun Oct 02, 2011 7:07 pm

I found the answer, it was hiding in YAGCD (5.7.2). Here's the updated code:

Code: Select all

void DVD_CallFunc(u32 fnAddress)
{
	dvd[0] = 0x14; //DEINT clr, TCINT clr
	dvd[1] = 0;
	dvd[2] = 0xFE120000;	
	dvd[3] = fnAddress;
	dvd[4] = 0x66756e63;	
	dvd[8] = 0;
	dvd[7] = 1;

}
I'll be implementing and committing this later on but I wanted to share it here first.
User avatar
emu_kidid
Site Admin
Posts: 4927
Joined: Mon Mar 29, 2010 10:06 am
Location: Australia
Contact:

Re: XenoGC fork

Post by emu_kidid » Mon Oct 03, 2011 4:26 am

nice work. I wasn't around to check this but it should be ok. just let me know if you run into any more issues.
Image
User avatar
emu_kidid
Site Admin
Posts: 4927
Joined: Mon Mar 29, 2010 10:06 am
Location: Australia
Contact:

Re: XenoGC fork

Post by emu_kidid » Mon Oct 03, 2011 4:28 am

one suggestion. Don't use DVD_Mount() since it does some drive unlock/crap. Use DVD_Reset(DVD_RESSETHARD); followed by a DVD_Read_Id (or similar names, I forget now).
Image
User avatar
megalomaniac
Posts: 2480
Joined: Sun Aug 21, 2011 5:33 am
Location: Drunk in Texas
Contact:

Re: XenoGC fork

Post by megalomaniac » Mon Oct 03, 2011 7:29 am

i finally got XenoAT.hex compiled in Linux..tested and running..
been working on this a few days already trying to figure out the key..
seems like its gonna require a build of binutils for mn10200 since the versions offered in devkitpro are not compatible.
for windows, its an easy build right out of the box with no issues...


more details later...
ill have to figure out something for the windows/Linux makefile since windows is funky
also ill have to try different avr-gcc, avr-binutils, avr-lib compatibility
emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
>>> BadAssConsoles.com <<<

Image Image Image
dantheman2865
Posts: 34
Joined: Sun Sep 04, 2011 3:24 pm
Location: Flint, MI, USA
Contact:

Re: XenoGC fork

Post by dantheman2865 » Tue Oct 04, 2011 12:43 pm

Emu, The Author was using "DVD_SetDebugMode();" which you had broken down into "DVD_SetDebugMode1();" and "DVD_SetDebugMode2();".
Given their use of some of your other DVD functions I am assuming this is the same function. It looks like this is Unlock 1 and 2; since we're not reading off the DVD in the XenoFlash program do we even need to do any disc setup?
User avatar
emu_kidid
Site Admin
Posts: 4927
Joined: Mon Mar 29, 2010 10:06 am
Location: Australia
Contact:

Re: XenoGC fork

Post by emu_kidid » Tue Oct 04, 2011 1:43 pm

This stuff is required because the DVD drive needs to be unlocked to accept debug commands, like to upload the custom drive code/etc.
Image
User avatar
megalomaniac
Posts: 2480
Joined: Sun Aug 21, 2011 5:33 am
Location: Drunk in Texas
Contact:

Re: XenoGC fork

Post by megalomaniac » Thu Oct 06, 2011 10:32 am

ive done a lot of testing and concluded the the following requirements for compiling XenoAT.hex under linux.
the most important requirement is to have gcc 3.4 installed to compile the tools needed for AVR and MN10200. Using newer versions of gcc may cause compile failures therefore, gcc 3.4 is recommended.
The required sources have been pre-packaged as XenoTools available at the googlecode xenogcfork page.



List of Required Source Packages included in XenoTools

Code: Select all

avr-libc-1.2.3
binutils 2.15-3
gcc-2.95.3
gcc-3.4.3


Preparation
create the following working directory:

Code: Select all

mkdir /opt/XenoTools
download XenoTools sources into: /opt/XenoTools
extract and extract some more
the following directories are created:

Code: Select all

/opt/XenoTools/avr-libc-1.2.3.orig
/opt/XenoTools/binutils-2.15
/opt/XenoTools/gcc-2.95.3
/opt/XenoTools/gcc-3.4.3


Directions:

Compile binutils 2.15 for AVR, MN10200 and MN10200-ELF

Code: Select all

cd /opt/XenoTools/binutils-2.15
mkdir mega
cd mega
../configure --prefix=/opt/XenoTools --target=avr
make
make install

make distclean
../configure --prefix=/opt/XenoTools/mn10200_binutils --target=mn10200
make
make install

make distclean
../configure --prefix=/opt/XenoTools/mn10200_binutils-elf --target=mn10200-elf
make
make install


Compile gcc 3.4.3 for AVR

Code: Select all

cd /opt/XenoTools/gcc-avr-3.4.3
mkdir mega
cd mega
../configure --prefix=/opt/XenoTools --target=avr --enable-languages="c" --program-prefix="avr-"
export PATH="${PATH}":/opt/XenoTools/bin
make
make install


Compile avr-libc 1.2.3 for AVR

Code: Select all

cd /opt/XenoTools/avr-libc-1.2.3.orig
./configure --prefix=/opt/XenoTools --host=avr
DO NOT MAKE/MAKE INSTALL YET...
The libc source requires a patch or something since its missing data for the Atmega8 which is our target microcontroller. Manually edit two Makefiles to provide support for the Atmega8.

Code: Select all

/avr-libc-1.2.3.orig/Makefile
/avr-libc-1.2.3.orig/crt1/Makefile

before: 
AVR_CRT_MEGA = 

after:
AVR_CRT_MEGA = crtm161.o crtm162.o crtm163.o crtm169.o crtm323.o crtm128.o crtm8.o crtm16.o crtm32.o crtm64.o
now we can continue..

Code: Select all

make
make install


Compile gcc 2.95.3 for mn10200

Code: Select all

cd /opt/XenoTools/gcc-2.95.3
./configure --prefix=/opt/XenoTools/mn10200 --target=mn10200-elf --enable-languages="c"
ONCE AGAIN, DO NOT MAKE/MAKE INSTALL YET...
Manually edit the Makefile in gcc directory and comment out "#" the following references to LIBGCC, LIBGCC1, and LIBGCC2.

Code: Select all

gcc-2.95.3/gcc/Makefile

before:
LIBGCC = libgcc.a
INSTALL_LIBGCC = install-libgcc
LIBGCC1 = libgcc1.a
CROSS_LIBGCC1 = libgcc1.cross
LIBGCC2 = libgcc2.a
LIBGCC2_DEBUG_CFLAGS = -g1
LIBGCC2_CFLAGS = -O2 $(LIBGCC2_INCLUDES) $(GCC_CFLAGS) $(TARGET_LIBGCC2_CFLAGS) $(LIBGCC2_DEBUG_CFLAGS) $(GTHREAD_FLAGS) -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
LIBGCC2_INCLUDES =
TARGET_LIBGCC2_CFLAGS = 
LIBGCC2_DEPS =
LIBGCC1_TEST = libgcc1-test

after:
#LIBGCC = libgcc.a
#INSTALL_LIBGCC = install-libgcc
#LIBGCC1 = libgcc1.a
#CROSS_LIBGCC1 = libgcc1.cross
#LIBGCC2 = libgcc2.a
#LIBGCC2_DEBUG_CFLAGS = -g1
#LIBGCC2_CFLAGS = -O2 $(LIBGCC2_INCLUDES) $(GCC_CFLAGS) $(TARGET_LIBGCC2_CFLAGS) $(LIBGCC2_DEBUG_CFLAGS) $(GTHREAD_FLAGS) -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  
#LIBGCC2_INCLUDES =
#TARGET_LIBGCC2_CFLAGS = 
#LIBGCC2_DEPS =
#LIBGCC1_TEST = libgcc1-test
now we can continue..

Code: Select all

make
make install
NOTE:
gcc 2.95.3 make might end with the following message:

Code: Select all

checking if compiler cc1obj has been built... no
rmdir: failed to remove `libobjc': Directory not empty

ignore this message, make is done, run make install




Cleanup
Remove the following directories:

Code: Select all

rm -rf /opt/XenoTools/avr-libc-1.2.3.orig
rm -rf /opt/XenoTools/binutils-2.15
rm -rf /opt/XenoTools/gcc-2.95.3
rm -rf /opt/XenoTools/gcc-3.4.3


DONE!!
now time to compile XenoAT.hex



edited: updated
Last edited by megalomaniac on Mon Oct 31, 2011 2:07 am, edited 1 time in total.
emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
>>> BadAssConsoles.com <<<

Image Image Image
dantheman2865
Posts: 34
Joined: Sun Sep 04, 2011 3:24 pm
Location: Flint, MI, USA
Contact:

Re: XenoGC fork

Post by dantheman2865 » Sun Oct 09, 2011 2:14 pm

I have an update on XenoFlash. Much of the drive functions are working. We were having an issue where once the flashloader has been transferred into the MN102 memory, the program would check a specific part of the memory and it would not return properly. While debugging this, i put a print statement in DVD_WriteDriveMemWord to make sure the proper bytes were being transferred and then it passed the check! I don't know why there would be a timing issue because we are using DVD_WaitImmediate to ensure the transfer is complete.

Anyway, once it passed that check I took a chance and tried flashing a new Xeno bin in there... and bricked my Xeno :lol:

I need to solder in my ISP, but hopefully this will be of assistance, Mega or Emu or whoever.

Thanks.
User avatar
megalomaniac
Posts: 2480
Joined: Sun Aug 21, 2011 5:33 am
Location: Drunk in Texas
Contact:

Re: XenoGC fork

Post by megalomaniac » Mon Oct 10, 2011 1:26 am

same here, i bypassed the check to continue testing functionality and attempt flashing...
i bricked also...
thats why i warned about having about having another DOL loading method, then using the official flasher to restore the chip...


it really makes no sense that the DVDread return does not match as expected..(or it does match as expected depending on how you look at the result)..
either way, i think one possibility for this is the flasher bin included in the source might be bad/corrupt...
..or also possible is we are not inserting properly..
emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
>>> BadAssConsoles.com <<<

Image Image Image
870663
Posts: 2
Joined: Sun May 09, 2010 4:19 am

Re: XenoGC fork

Post by 870663 » Tue Oct 11, 2011 9:37 pm

We were having an issue where once the flashloader has been transferred into the MN102 memory, the program would check a specific part of the memory and it would not return properly.
where exactly did it hang?
User avatar
megalomaniac
Posts: 2480
Joined: Sun Aug 21, 2011 5:33 am
Location: Drunk in Texas
Contact:

Re: XenoGC fork

Post by megalomaniac » Wed Oct 12, 2011 1:15 am

870663 wrote:
We were having an issue where once the flashloader has been transferred into the MN102 memory, the program would check a specific part of the memory and it would not return properly.
where exactly did it hang?

After injecting the drivecode "CMD_InjectCustomDriveCode()" the next action is "CheckDriveState(true)"...
while checking the drive state, "dwIntVec" is equal to 0xDDDDDDDD

thats where it hangs...
emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
>>> BadAssConsoles.com <<<

Image Image Image
Post Reply