But I did not check in the libgcc files. Instead I added inclusion of gcc --print-libgcc in the make process. Can you try whether this works for you?
Maybe when not cross-compiling, but that's way too slow for me. I have built four different versions of cross-gcc's and while they all can compile, none has a working libgcc. That's why I had to remove the linking to libgcc and add the files. I think not using system libgcc is cleaner way, the same approach as taken in Linux kernel. Another solution would be getting rid of long long arithmetic.
Here's my current version against SVN revision 3. I added most of the devices to the tree.
There are two zs devices, but the other one can't be reached: 2 > cd /obio ok 2 > ls -2bc228 interrupt@0 -2bc180 counter@0 -2bc0dc eeprom@0 -2bc024 zs@0 -2bbed4 zs@0 ok 2 > cd zs ok 2 > .properties name "zs" device_type "serial" reg -- c : 0 0 0 0 0 0 0 0 0 0 0 8 slave 1 model "mk48t08" intr -- 8 : 0 0 0 2c 0 0 0 0 keyboard 1 mouse 1 ok
In real hardware, the zs nodes are named zs@0,0 and zs@0,100000. Maybe the address has some effect to naming?
_________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
* Blue Swirl blueswir1@hotmail.com [060426 22:10]:
Maybe when not cross-compiling, but that's way too slow for me. I have built four different versions of cross-gcc's and while they all can compile, none has a working libgcc. That's why I had to remove the linking to libgcc and add the files. I think not using system libgcc is cleaner way, the same approach as taken in Linux kernel. Another solution would be getting rid of long long arithmetic.
I see.
Maybe we should pack that stuff in a subdirectory of those platforms that need it.
Dropping long long arithmetics is not an option as we need 64bit integer variables in the OpenBIOS forth kernel to comply with IEEE 1275-1994.
Going to some non-native implementation would probably be doable but it would also make the thing unneccesarily big and slow.
2 > .properties name "zs" device_type "serial" reg -- c : 0 0 0 0 0 0 0 0 0 0 0 8 slave 1 model "mk48t08" intr -- 8 : 0 0 0 2c 0 0 0 0 keyboard 1 mouse 1 ok
In real hardware, the zs nodes are named zs@0,0 and zs@0,100000. Maybe the address has some effect to naming?
yes, the parent node needs a decode-unit and encode-unit method. See drivers/pci.fs
Stefan
Going to some non-native implementation would probably be doable but it would also make the thing unneccesarily big and slow.
I'll try to find portable versions if you prefer those. I think .div and friends are sparc-specific.
yes, the parent node needs a decode-unit and encode-unit method. See drivers/pci.fs
Ok, I'll check.
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
* Blue Swirl blueswir1@hotmail.com [060426 22:10]:
Here's my current version against SVN revision 3. I added most of the devices to the tree.
Just browsing through the patch.. Why's the checksum hack?
Stefan
Just browsing through the patch.. Why's the checksum hack?
The checksum calculation doesn't get correct results for some reason, and I just wanted to delay investigating that issue. First I thought it was a cross-compilation problem, but natively compiled version is not correct either.
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-
Blue Swirl -
Stefan Reinauer