Printable View
I don't see an error in the Xorg log file. If the grey screen apears, it is correct and you need just to wait longer. xfce4 needs more than 30 minutes to start from internal hard disc. If you start from USB, it will take much more time. Without a swap partition there is no chance to start it.
When you reduce the video memory to the minimum, it will be faster.
For 640x480-32 it is 1228800 Bytes.
For 640x480-16 it is 614400 Bytes.
MegaMan, but why it become so long? I can right now to load old distributions like kit or with 2.4 kernel and it will start X for me without any question!
Is problem in kernel2.6 or in new packages? Is it reasonable to make old packages of fluxbox and it's dependences?
No, i have 512mb loop swap file on flesh and add it in fstab instead of /dev/hda2 partition.Quote:
Originally Posted by MegaMan
I could to build your cross-compiler for 2.6 32bit-kernel, MegaMan and i want that it's work don't end on it. I want to use it in qemu through distcc. Cross-compiling for itself:evilgrin::crazy:
I read and re-read, and try and re-try all instructions about creating network between virtual-machine qemu and local machine, but distcc each time said that "No route to host". But pings, ssh-connections VM-local local-VM are past. Distcc through ssh don't work also too - something about non-socket operation on socket... or on the contrary.
What info i used:
http://ru.gentoo-wiki.com/wiki/Подкл...ть
Distcc over SSH - Gentoo Linux Wiki
Sorry for my lovely Russian:rolleyes: Intuitively clear.
Maybe someone already did compiling using distcc from qemu? Or came across instruction about this great idea? IN DETAILS, please.
And, MegaMan, what about questions above?)
-----------------------------------------------------------------------------
I launch linux 2.4 kernel and found smth interesting.
No xorg. XFree86 instead it. And wmaker instead of xfce64-session or fluxbox.
Here is a piece from /etc/XGSConfig (analog of /etc/X11/xorg.conf)
At least another special driver ->gsx<-Code:# The GS server
Section "Screen"
Driver "gsx"
Device "Graphics Synthesizer"
DefaultColorDepth 24
# DefaultColorDepth 16
FrameRate 60
# FrameRate 75
# VideoMode "VESA"
# VideoMode "NTSC" "interlace"
# VideoMode "PAL" "nointerlace"
# VideoMode "DTV"
# interlace-mix 35
SubSection "Display"
Depth 16
# Modes "480p" "720p" "1080i"
Modes "1280x1024" "1024x768" "800x600" "640x480"
# Modes "1024x768" "800x600" "1280x1024" "640x480"
EndSubSection
SubSection "Display"
Depth 24
# Modes "480p" "720p"
# Modes "1024x768" "800x600" "640x480"
Modes "800x600" "640x480"
EndSubSection
EndSection
This graphic driver is from XFree86-gs-3.3.6-1aEE.mipsel.rpm (kit) or from kernel? And maybe we should to install old XFree86, try it and then upgrade it or to leave xorg?
All packages and the kernel need more memory which makes it slower.
The distcc doesn't support mixing of native and cross-compiling. You need to adapt the script to force the prefix "mipsel-linux-gnu-". The distcc assumes that the compilers on all systems have the same name.
The purpose of my cross-compiler is to compile the Linux kernel. If you want to compile a user space software, you need to use the unpatched mips compiler.
The tun and tap devices are like a tunnel. The ip addresses are different on each side. You need to make sure to use the correct one on each side.
On the real computer the distcc needs to run on the ip address which you can see with ifconfig after starting qemu. There must be a tun device.
On the qemu side you need to use the ip address which is within the network which you can see with ifconfig in qemu.
I assume that installing old software within a newer version will not work easily. A chroot to the old stuff should work until the registers k0 or k1 are used to implement fast user space atomic read and update operations. I don't know if the old gsx driver is able to handle a frame buffer driver.
But if it will didn't find corss-compiler it will use native compiler.Quote:
Originally Posted by MegaMan
Yes, i did links like mipsel-linux-gnu-gcc -> gcc in qemu. It need but case not in it.Quote:
Originally Posted by MegaMan
Your cross-compiler, as you said, use hi1 and lo1! So if it not differ from another mipsel-linux-gnu compiler, why it not to use?!Quote:
Originally Posted by MegaMan
I did compiling some package on qemu. Some file compiling so long, that i, just so on guess, went to same directory and launch same long command, that printed in qemu's terminal, but with mipsel-linux-gnu-g++ in begin. It successfully compiled (just because no libraries and header files of system are needed) by 2-4 seconds. I did terminate compiling proccess in qemu and paste compiled file to needed directory in qemu and continue the compiling.
And package at all compiled with just this warning:
::binary:: use hard float, but ::compiled by cross-compiler file:: use soft float
For ps2linux it just whatever right?) At all i can't to try this package cause it use Xes:mad:
About tun and tap devices. I did create virtual network device tap. As I said, i did ifconfig and did pings on these IPs. SSH command successfully past from each to other machine. In detailes:
distccs on each machine are same version 3.1
On host machine:
>sh tun< script, where:
tun
modprobe tun
ifconfig eth0 0.0.0.0 promisc
tunctl -t tap1 -u distcc
ifconfig tap1 0.0.0.0 up
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 tap1
ifconfig br0 192.168.168.251 netmask 255.255.255.0 up
ifconfig: tap1 as eth0 as =br0 IP is 192.168.168.251
mipsel-linux-gnu-gcc and another "friends" are already in PATH - in /usr/local/bin directory
distccd --daemon --allow 192.168.168.252
ps -ef | grep distccd - checked
On qemu, run by
how runs qemu
qemu-system-mipsel -hda hda.img -m 256 -kernel vmlinux-2.6.26-2-4kc-malta -append "root=/dev/hda1 console=ttyS0" -nographic -net tap,ifname=tap1,script=no -net nic
/etc/network/interfaces:
export PATH=/usr/lib/distcc:$PATH, where areCode:auto eth0
iface eth0 inet static
address 192.168.168.252
netmask 255.255.255.0
network 192.168.168.251
broadcast 192.168.168.1
gateway 192.168.168.252
links like mipsel-linux-gnu-g++ -> g++ and g++ -> /usr/bin/distcc
export DISTCC_HOSTS=192.168.168.251
cd /path_to/SDL-1.2.13 (SDL as example. Just placed here...)
./configure
make
...
and compiling locally:mad:Code:distcc[1456] ERROR: nonblocking connect to 192.168.168.251:3652 failed: No route to host
distcc[1456] Warning: failed to distribute ./src/SDL_fatal.c to 192.168.168.251, running locally instead
Another way:
export DISTCC_HOSTS=root@192.168.168.251
...
make
...
distccd[2439] (tcp_cork_sock) Warning: setsockopt(corked=1) failed: Socket operation on non-socket
Ooops...:rolleyes::lol: I just RIGHT NOW noticed, that it is JUST WARNING!!!:dance: Ok, then now problem in ssh that compiling every file asking me for root@192.168.168.251's password.
ssh-keygen is not working... need to understanding and another instruction to read.
[QUOTE=MegaMan]if the old gsx driver is able to handle a frame buffer driver[QUOTE]
If driver in kernel (not in package) if it is not so hard would you be so king as to add this driver to test in 2.6_v9!!!
And memory card partition to mount, and cifs or smbfs to mount:D
Neither my cross-compiler nor the unpatched compiler use hi1 and lo1. Generating of ldc1 and sdc1 is disabled in my cross-compiler which increases the execution speed. Maybe it is more compatible in 32 bit mode than I thought. The most differences seem to be mips64el related which is not used.Quote:
Originally Posted by archicharmer
In your case you need to enable hard float. The Linux kernel should use soft float.Quote:
Originally Posted by archicharmer
The broadcast address seems to be bad. I never heard of the keyword "network" in this file.Quote:
Originally Posted by archicharmer
The gsx driver is not part of the kernel.Quote:
Originally Posted by archicharmer
MCFS is not finished. As far as I remember CIFS was working. Now I added my last version which used modules v7. This builds an initrd which can mount a loop file as rootfs over CIFS. You can test it and optmize usability.Quote:
Originally Posted by archicharmer
SourceForge.net Repository - [kernelloader] Index of /linux/busybox
EDIT: I think swap file over CIFS was unstable (system freeze). losetup is needed to configure it, otherwise the file has "holes".
EDIT2: I checked the GCC patch. My result is that no patch is needed for mipsel to build the kernel. The patch is only needed to build the 64 bit kernel. I am concentrating on a 32 bit kernel with support for 64 bit, so I disabled all GCC patches in the build scripts.
I'm trying to compile XFree86-3.3.6-with-gsx. (I tried to compile v4.3.0 but Xaw6 looking for kernel-headers... therefore 3.3.6)
It all compiled... except gsx, exactly xc/programs/Xserver/hw/gsx
Unable to emulate 'TI'. Only old ps2 toolchain and mips64r5900el-toolchain can emulate. Old ps2 toolchain build mips3, but lenny need mips1.
Is there a way to add smth to your SourceForge.net Repository - [kernelloader] Index of /linux/simple-toolchain
to emulate 'TI'?
Or another way to use smth instead of TI?
gsostype.h, line 43
typedef unsigned int GSOSbit128 __attribute__((mode(TI)));
and lower a function what used lo1 and hi1. Better to look on it.
MegaMan, where are your old toolchain patches for hi1 and lo1? Please, share them.
The hi1 and lo1 patches are in no way related to the members hi1 and lo1 in the file gsostypes.h.
I suggest to remove the lines:
typedef unsigned int GSOSbit128 __attribute__((mode(TI)));
GSOSbit128 ti;
Then replace each occurrence of GSOSbit128 by GSOSQword. If anything is copied, you need to use the memcpy() function.
Chewi claimed to have added support for TI to the GCC. I think TI is only supported by mips64el.
did. First file is compiled.Quote:
Originally Posted by MegaMan
Not understood. Next file gived me a lot of lines with errors like "unreqognized opcode ......"Quote:
Originally Posted by MegaMan
It is all going to that for full functionality of ps2-linux we need 64-bit kernel!
Just don't use the TI type, use something else which have the same size.Quote:
Originally Posted by archicharmer
The binutils doesn't include all assembler instructions. You need to insert the missing ones in the file binutils-2.20.1/opcodes/mips-opc.c from #3899003 - Pastie. You need to do this manually. I didn't inserted it, because I don't have a testsuite for this.Quote:
Originally Posted by archicharmer
No, the 64-bit kernel is not needed, only a 64 bit toolchain which uses 32 bit for addresses. The 32-bit kernel has support for 64-bit and 128-bit registers.Quote:
Originally Posted by archicharmer