Ah... it is so hard for me. I hope, when i apply patch what you gave for binutis all be correct.Quote:
Originally Posted by Mega Man
Does it mean i can install 64-bit linux? Fedora 13 mips64el for example. ?Quote:
Originally Posted by Mega Man
Printable View
Ah... it is so hard for me. I hope, when i apply patch what you gave for binutis all be correct.Quote:
Originally Posted by Mega Man
Does it mean i can install 64-bit linux? Fedora 13 mips64el for example. ?Quote:
Originally Posted by Mega Man
If it is build with n32 abi, it will work until a syscall is executed. The syscall mapping table for n32 is not included. If the code uses o32 ABI syscalls, it should work.
This patch for binutils-2.16.1 for opcodes/mips-opc.c is not enough. It is from mips64r5900el-toolchain? patch №97
Ok, i did unpack Index of /Fedora-13-rootfs-MIPS fedora-13-rootfs, unpack modules-v8 all to loop-file, edited fstab and tried to launch.
After "Changing root."
request_module: runaway loop modprobe binfmt-464c
and stops.
'file' of one binary:Quote:
Originally Posted by Mega Man
ELF 32-bit LSB executable, MIPS, N32, MIPS-III version 1, dynamically linked (uses shared libs), for GNU/Linux 2.6.18, with unknown capability 0xf41 = 0x756e6700, stripped
while 'file' of one debian's binary:
ELF 32-bit LSB executable, MIPS, MIPS-I version 1, dynamically linked (uses shared libs), for GNU/Linux 2.6.8, with unknown capability 0xf41 = 0x756e6700, stripped
Will it work? It's look like it just only want some module...
Currently it is not working. I think it is possible to add support.
!!! It would be great! I think, by this doing we shot into the problem with memory.Quote:
Originally Posted by Mega Man
Also, at last i can try mips64r5900el-toolchain!
So, if you guys have a working copy of a modern GCC compiler (GCC 4.x), what do you guys think are the odds of it being accepted by the GCC committee? It'll be good if support for the PS2's MIPS R5900 EE gets officially included into modern GCC versions.
The reason why this was not done before with GCC 3.2.2 was because the developers basically created a version of GCC that was so hacked up that support for other systems was broken.
My last result was that there is no patch for GCC needed. The following command line parameters will make mipsel-linux-gnu-gcc compatible:
-Wa,-march=r5900 -mno-llsc -msym32
mips1 will be used by the GCC. This will work with kernel and homebrew code.
Only binutils are patched in the current state.
For optimizing purpose there may be a GCC patch needed, but Linux 2.6 is able to execute the code without patches for GCC, because every unsupported instruction will be emulated.
The old GCC 4.3 patches are not clean and simply disables all unsupported instructions. The GCC committee will not accept patches for GCC 4.3. I think only patches for the latest version will be accepted. Converting the patches to newer versions always prooved to be impossible. Patches for newer versions must be always generated from scratch. The best way is to have a GCC version which behaves like the normal mips GCC and EE support can be activated with -march=r5900. We need a testsuite for it which is included in the GCC. This allows the GCC maintainers to keep the patches up to date.
I decided to try new initrd.
In bootsamba.sh i wrote:
- same line which i mount SharedDocs of WindowsXP to Fedora on Virtual Machine.Code:echo "Connect to samba server"
mount -t cifs -o rw,username=guest,password=1,ip=192.168.168.149 //great/SharedDocs /mnt
Not mounted - "bad server 'great'". Doesn't matter where is place of "//great/SharedDocs /mnt" in command line - before >-o< or after.
Where is bash? Please, Mega Man, do "exec bash" if error - then i can to try ping and to find needly command line.
I did try to load old 2.4 linux with 2.6 kernel. Now, i forgot to copy modules of 2.6.35.4 and... it loads (fast as with 2.4 kernel) on USB WITH Xes! But without mouse (maybe because no joymouse module in 2.6 kernel). I could not enter to terminal from "desktop".
Loading once again. Now, with 2.6.35.4 modules. No module - no mouse.
Loading once again. Ctrl+C when start x. First command - "ls" - no effect. Most simply commands are works, but ls.
Now, as always, questions:) So, if we can't compile 64-bit kernel...
Is there a way to got 32-bit output binaries from 64-bit toolchain? Maybe some flags? If they, how to use these flags?
I think, that if mips64r5900el-toolchain will be giving 32-bit libraries, it is equivalent of mipsEEel-toolchain. (From patch of binutils-2.9EE - mipsEEel: basic_machine=mips64r5900el-sky). What flags are used by mipsEEel-toolchain-gcc?
Maybe we can use old installed linux with 2.6 kernel?
1. Copy all needed headers from 2.6.35.4 kernel source to needed directory of installed 2.4 ps2linux with replacing;
2. With the help of mips64r5900el-toolchain to compile 32-bit glibc for toolchain itself and copy it to needed directory of installed 2.4 ps2linux;
3. Do native compiler from mips64r5900el-toolchain - the most difficult. In mipsEEel-toolchain in directory lib/gcc-lib/mipsEEel-linux/3.0.3/ there is file "specs". I didn't find same file with gcc-4.3.5. Well, we need to add needed flags here.
No way, except to compile new packages for total ps2linux by it's native compiler. PS2Linux, loaded by smb, with swap compiles packages a little more slowly than qemu-mipsel.
i always mount by mount.cifs \\\\1.2.3.4\\some\\share /some/where -o <options>; well, not on ps2.
The initrd stuff is not finished.
As far as I know the parameters are different: user and not username, passwd and not password. I would never use a server name. The Windows stuff is unpredictable. I always use the IP address instead.
ABI n32 is the closest format to the old toolchain regarding GCC, because it suports 64 bit registers and 32 bit adresses. For libc this is not the case because of the o32 syscalls.
I don't know why you want to compile old BlackRhino with a new compiler.