Tiny Core Linux
Tiny Core Base => Corepure64 => Topic started by: Juanito on November 13, 2012, 12:52:32 AM
-
Team Tinycore is pleased to announce corepure64 - a fully 64-bit version of tinycore for x86_64.
- Based on version 4.7 of core/core64
- Fully 64-bit toolchain and base applications/libraries using the same source versions as core/core64
- Uses vmlinuz64 and the kernel modules *-tinycore64 from core64
- Not compatible with 32-bit extensions from core/core64
- Uses Xorg-7.6 as Xvesa is not 64-bit compatible
- compiletc toolchain available to build user supplied extensions
- editor/fluff and basic gtk2 applications available
Distribution files are available at: http://distro.ibiblio.org/tinycorelinux/4.x/x86_64
User feedback would be welcomed and much appreciated. As this is a first version, please approach with care and do not use on production systems.
Tested on one (dell e6220) machine with intel hd3000 graphics hardware and broadcom wireless.
Due to the (somewhat) protracted development cycle, some extensions are outdated as compared to the x86 repo, please feel free to add and update.
Edit: To clarify:
core64 - each 32-bit app can use up to 4gb of ram
corepure64 - each 64-bit app is only limited by the ram available
-
That's awesome thanks :)
-
...
User feedback would be welcomed and much appreciated. As this is a first version, please approach with care and do not use on production systems.
...
Tested (briefly) on Dell PowerEdge SC440 (one dual core cpu) and Dell Precision 1500 (1 quad core cpu) - excellent on both.
Excellent release. Thank you.
-
Tested on AMD Athlon 64 X2 Dual Core 4200+ with 4GB RAM. Works fine, no issues foune
:)
-
To check toolchain built liblzma.tcz and xz.tcz using my piCore build scripts. Without any modification extensions built, working as expected. Its great.
Tried ncurses applications, mc and htop. It fails due to lack of ncurses header files. ncurses-dev.tcz installed, there is something wrong.
-
I think you may have to tell mc & htop that the ncurses headers are in /usr/local/include/ncurses in their ./configure scripts?
-
I think you may have to tell mc & htop that the ncurses headers are in /usr/local/include/ncurses in their ./configure scripts?
Will check what is wrong later, but my build scripts are working on x86 and piCore versions :( So there is something different here.
-
tc@box:~/Downloads$ la
total 6396
drwxr-xr-x 2 tc staff 80 Nov 14 15:07 ./
drwxr-s--- 15 tc staff 620 Nov 14 14:54 ../
-rw-r--r-- 1 tc staff 6532297 Nov 14 15:07 corepure64.gz
-rw-r--r-- 1 tc staff 48 Nov 14 15:06 corepure64.gz.md5.txt
tc@box:~/Downloads$
tc@box:~/Downloads$ cat corepure64.gz.md5.txt
cfbbc116c4824223ba627e2515754cdf corepure64.gz
tc@box:~/Downloads$ md5sum corepure64.gz
f8e54893041a2dfaaa2d0ba8b0fac764 corepure64.gz
tc@box:~/Downloads$
-
I take it you mean there's a problem with the checksum.
I deleted and uploaded corepure64.gz again - from the repo on ibiblio: $ cat corepure64.gz.md5.txt
f8e54893041a2dfaaa2d0ba8b0fac764 corepure64.gz
$ md5sum corepure64.gz
f8e54893041a2dfaaa2d0ba8b0fac764 corepure64.gz
-
I think you may have to tell mc & htop that the ncurses headers are in /usr/local/include/ncurses in their ./configure scripts?
Yes, specifiying explicitly solves the problem. htop builds fine, will submit. There is an issue with mc, will investigate.
In x86 and picore ncurses headers are in /usr/local/include so configure works without extra arg.
-
In x86 and picore ncurses headers are in /usr/local/include so configure works without extra arg.
That's where ncurses put them by default and I left them there as it made it easier to symlink them to /usr/include in order for "make menuconfig" to work with a kernel source.
-
That"s OK. I will change in piCore and probably in x86 to be in sync.
-
This is wonderful.
I can now use and maximize my RAM in Tiny Core.
-
just to be clear:
core64 - each 32-bit app can use up to 4gb of ram
corepure64 - each 64-bit app is only limited by the ram available
-
just to be clear:
core64 - each 32-bit app can use up to 4gb of ram
corepure64 - each 64-bit app is only limited by the ram available
While that was not particularly unclear (at least to me), I can see where someone new to Core might not immediately see the distinction. It might be worth while to add those few lines to the original post of this thread.
-
juanito....ur a legend....total legend....thx so much
-
done
-
This is superb
A proper, fully supported ,64 bit build of the tinycore Linux operating system.
So many computer boards and chips support 64bit. It's such a waste
to not have an operating system and applications that can use 64 bit hardware.
i feel many people will be interested in this build.
thanks
V.
-
Is Xfbdev compatible with corepure64 ?
-
Also nvidia-module-3.0.21-tinycore64.tcz dep file depmod.tcz is missing from repo
:(
-
Hi coreplayer2
I just checked the repository, depmod.tcz is in there.
-
Hi Rich, I'm looking for it here /tinycorelinux/4.x/x86_64/tcz/
ok, must be a part of busybox
thanks
-
Hi coreplayer2
Sorry, my mistake. I wasn't paying attention, I looked in the 32 bit repository.
-
I'm confused, isn't depmod part of busybox ? or does the extension require the full version ? (which apparently is missing)
-
depmod is part of Xorg source
-
currently BusyBox version of depmod is in PATH
Is that sufficient? does this meet the requirements of a dep which requires depmod.tcz ?
-
I'm not at a tc machine to check, but since the depmod extension would provide the full depmod in /usr/local, that would come before busybox depmod in the PATH statement, no?
Or are you saying you'd like the full depmod available as an extension? I hadn't spotted that depmod was required by one or more extensions - did you try the nvidia extension without it to see if it worked?
-
yes, the dep file for nvidia-module-3.0.21-tinycore64.tcz lists depmod.tcz as a dependency, but does not exist in the x86_64 repository.
currently, only the busybox version of depmod is running since it's in PATH with no other version to supersede it.
Was hoping that this was this missing link in getting Xorg to run on a Macbook.
the system runs great with x86_64 from the command-line, but never loads X
attempting " startx " from the command line produces a " cat: can't open ' /etc/sysconfig/Xserver ' : no such file or directory " error
Previously, the only X I have been able to get running with the Mac x64 system was Xfbdev. Looking at the great support for x86_64 with the available drivers with this x86-64 deployment I was hoping to run Xorg on this system finally, alas Xorg so far refuses to run.
-
I'm pretty sure I have a 64-bit version of the full depmod somewhere - give me a couple of days and I'll dig it out.
In the meantime, if you can access the command line, you could always compile it from module-init-tools (I think)...
-
Ok thanks, meanwhile am running with text boot code.
Without the text boot code we are at the point during boot where tc loads, runs the boottime scripts, displays the logo and a command prompt for a split second then becomes a blank screen where normally Xorg/Xfbdev would load
I have " text " " norestore " boot codes, yet when booted up to the command line I notice that .xsession contains " Xvesa -br etc etc " on the first line. Shouldn't the first line say /usr/local/bin/Xorg etc etc" ?
/etc/sysconfig/Xserver reads Xorg on first line
-
The Xorg-7.6 extension will start without problems even though the initial .xsession references Xvesa
-
Ok thanks for the clarification.
May I request a x86_64 version of Xfbdev please :)
-
I'm pretty sure I have a 64-bit version of the full depmod somewhere - give me a couple of days and I'll dig it out.
depmod extension posted
-
Thanks, am going to take it for a spin soon
Thanks again
-
Looks like I have a new Broadcom Gigabit Ethernet driver (for adapters used in all 2012 Mac mini's) built for Core64/CorePure64, almost finished.
still testing
-
my mac mini (2011, I guess) has this:
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM57765 Gigabit Ethernet PCIe (rev 10)
..and works with the base core64
-
Apple changed the Ethernet adapter in all new Mac mini's6,x (at least 6,1 & 6,2) to BCM57766, the tg3 drive in base will no longer work with these new devices :|
Broadcom has an updated Tigon tg3.ko driver v 3.124c with many enhancements over the older version which is in the latest Linux kernel, but not 3.0.21.
I have compiled a driver using corepure in text mode and made an extension, works great once the old tg3 is removed and the new tg3 modprobe'd
Assuming this is the right way to accomplish the task, Just need to write a start-up script to run
sudo modprobe -r tg3
sudo modprobe tg3
sudo /opt/eth0.sh
Unless there is a better way
-
You could remaster corepure64 and replace tg3.ko.gz with your driver
-
Meanwhile this script work out to install the tg3 driver on boot
#!/bin/sh
## function DHCP reset
f_dhcp() {
sudo pkill udhcpc
sleep 0.5
sudo udhcpc -b -i eth0 -x hostname:box -p /var/run/udhcpc.eth0.pid
}
## function driver install
f_tg3_install() {
KMOD=/tmp/tcloop/eth-tg3-3.0.21-tinycore64/lib/modules/3.0.21-tinycore64/kernel/drivers/net
KDIR=/lib/modules/3.0.21-tinycore64/kernel/drivers/net
## if tigon3 driver loaded, unload driver
[ -n 'lsmod | grep "tg3"' ] && sudo modprobe -r tg3.ko
## remove old tg3 driver & replace with updated tg3-3.124c driver
find ${KDIR} -name tg3.ko.gz | xargs rm -f
cp ${KMOD}/tg3.ko.gz /${KDIR}/tg3.ko.gz
## load driver, bring up & start DHCP
sudo modprobe tg3.ko && sudo ifconfig eth0 up && f_dhcp >/dev/null 2>&1
}
## Detect Broadcom Ethernet & install updated if true
ETHX=`lspci | grep "Ethernet controller" | grep "Broadcom"`
[ -n "$ETHX" ] && f_tg3_install
-
You could remaster corepure64 and replace tg3.ko.gz with your driver
Actually I didn't realize how easy this might be, if the drivers test out good with the above script I think I'll do exactly as you've suggested above.
Thanks
lol easy, right..
-
Thanks juanito for your effort in creating an Xfbdev extension, works well.
great job thanks
-
Sorry to ask this probably dumb question but is it possible to use xfce4 or lxde from 32-bit?
-
No, but they will work with core64
-
ok thank you :)
-
You could remaster corepure64 and replace tg3.ko.gz with your driver
Thanks for the idea, works like a champ now with all new Mac mini's
remastered coreplus64 and core64 both with new tg3 Ethernet driver compiled for x86_64
Thanks again for all your help Juanito
-
'Glad to hear it works :)