XenoGC fork
XenoGC fork
I just opened a googlecode page for this. Let me know if you want into it etc.
http://code.google.com/p/xenogcfork/
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
(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
-
- Posts: 34
- Joined: Sun Sep 04, 2011 3:24 pm
- Location: Flint, MI, USA
- Contact:
Re: XenoGC fork
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?
Re: XenoGC fork
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
(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
Re: XenoGC fork
Some progress on making the shell boot a special file that it automatically finds on memory card:
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!
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
Re: XenoGC fork
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.
Details will come tomorrow on what I did to get the file onto the memory card/etc.
- Attachments
-
- Image0930-0106(CVBS)(1).jpg
- (14.11 KiB) Not downloaded yet
-
- Image0930-0106(CVBS).jpg
- (10.66 KiB) Not downloaded yet
-
- Posts: 34
- Joined: Sun Sep 04, 2011 3:24 pm
- Location: Flint, MI, USA
- Contact:
Re: XenoGC fork
Awesome! I'll try to take a look through the code. Will the next version of Swiss support loading files to the memory card?
Re: XenoGC fork
PM emu_kidid
Playing - Super Mario Sunshine - DariusBurst CS - Hotline Miami 2 - Rpi2 Lakka - X360 BurnOut Paradise City
Re: XenoGC fork
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:
Besides these issues, it works just fine.
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:
Doltool doesnt complain.Warning: writable and executable segment 0
Error: TEXT segment 0 memory size (0x1578) does not equal file size (0xd18)
Besides these issues, it works just fine.
Re: XenoGC fork
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
(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
- megalomaniac
- Posts: 2480
- Joined: Sun Aug 21, 2011 5:33 am
- Location: Drunk in Texas
- Contact:
Re: XenoGC fork
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:Doltool doesnt complain.Warning: writable and executable segment 0
Error: TEXT segment 0 memory size (0x1578) does not equal file size (0xd18)
Besides these issues, it works just fine.
compare your makefile with the posted r8 update
my bin size compiled same as original 3.3k
>>> BadAssConsoles.com <<<emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
Re: XenoGC fork
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.
So I think I fixed it with the r5 when I shut up the compiler warnings.
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.
So I think I fixed it with the r5 when I shut up the compiler warnings.
-
- Posts: 34
- Joined: Sun Sep 04, 2011 3:24 pm
- Location: Flint, MI, USA
- Contact:
Re: XenoGC fork
@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!
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!
-
- Posts: 34
- Joined: Sun Sep 04, 2011 3:24 pm
- Location: Flint, MI, USA
- Contact:
Re: XenoGC fork
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?
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!
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, ???);
}
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!
-
- Posts: 34
- Joined: Sun Sep 04, 2011 3:24 pm
- Location: Flint, MI, USA
- Contact:
Re: XenoGC fork
I found the answer, it was hiding in YAGCD (5.7.2). Here's the updated code:
I'll be implementing and committing this later on but I wanted to share it here first.
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;
}
Re: XenoGC fork
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.
Re: XenoGC fork
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).
- megalomaniac
- Posts: 2480
- Joined: Sun Aug 21, 2011 5:33 am
- Location: Drunk in Texas
- Contact:
Re: XenoGC fork
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
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
>>> BadAssConsoles.com <<<emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
-
- Posts: 34
- Joined: Sun Sep 04, 2011 3:24 pm
- Location: Flint, MI, USA
- Contact:
Re: XenoGC fork
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?
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?
Re: XenoGC fork
This stuff is required because the DVD drive needs to be unlocked to accept debug commands, like to upload the custom drive code/etc.
- megalomaniac
- Posts: 2480
- Joined: Sun Aug 21, 2011 5:33 am
- Location: Drunk in Texas
- Contact:
Re: XenoGC fork
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
Preparation
create the following working directory:
download XenoTools sources into: /opt/XenoTools
extract and extract some more
the following directories are created:
Directions:
Compile binutils 2.15 for AVR, MN10200 and MN10200-ELF
Compile gcc 3.4.3 for AVR
Compile avr-libc 1.2.3 for 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.
now we can continue..
Compile gcc 2.95.3 for mn10200
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.
now we can continue..
NOTE:
gcc 2.95.3 make might end with the following message:
ignore this message, make is done, run make install
Cleanup
Remove the following directories:
DONE!!
now time to compile XenoAT.hex
edited: updated
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
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
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
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"
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
Code: Select all
make
make install
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.
>>> BadAssConsoles.com <<<emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
-
- Posts: 34
- Joined: Sun Sep 04, 2011 3:24 pm
- Location: Flint, MI, USA
- Contact:
Re: XenoGC fork
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
I need to solder in my ISP, but hopefully this will be of assistance, Mega or Emu or whoever.
Thanks.
Anyway, once it passed that check I took a chance and tried flashing a new Xeno bin in there... and bricked my Xeno
I need to solder in my ISP, but hopefully this will be of assistance, Mega or Emu or whoever.
Thanks.
- megalomaniac
- Posts: 2480
- Joined: Sun Aug 21, 2011 5:33 am
- Location: Drunk in Texas
- Contact:
Re: XenoGC fork
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..
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..
>>> BadAssConsoles.com <<<emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving
Re: XenoGC fork
where exactly did it hang?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.
- megalomaniac
- Posts: 2480
- Joined: Sun Aug 21, 2011 5:33 am
- Location: Drunk in Texas
- Contact:
Re: XenoGC fork
870663 wrote:where exactly did it hang?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.
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...
>>> BadAssConsoles.com <<<emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving