Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: roberts on August 13, 2012, 04:19:30 PM
-
With the many arm platforms and their specific configurations my approach is to create a kit.
Like a remastering tool to be based on using an actual current core.gz and updating it to arm via existing known working Arm distribution.
This way we can jump start on open community development on several arm platforms. Without having to initially build all the necessary support tools and GPL compliant sources. Don't make such a commitment until you know the results would be worth the effort!
This approach also allows our strong and very talented community to participate in the early stages of development.
Call it protyping, jump starting, or remastering your own arm Core system. I have now posted the first cut of such an approach.
http://distro.ibiblio.org/tinycorelinux/4.x/arm/armv6/picore-kit.tgz
It contains three small scripts, Core custom compiled arm binaries and their sources.
Please be certain to read the README as one can easily wipe out a hard drive or an existing Debian Arm sdcard.
Comment, suggestions, patches, etc are all welcomed.
Who knows, hopefully this approach will be successful and via our community be extended to jump start other Arm platforms.
If and when such time all the PiCore sources and infrastructure have been completed then an image with GPL compliant sources can be hosted. Until such time, those who are comfortable with reading and running scripts, well, let the fun begin.
-
hi roberts,
thank you for your efforts behind the scenes!
one question:
is there a reason that you took the debian6-19-04-2012.zip,
in the moment the 2012-07-15-wheezy-raspbian.zip is the actual one!?
is it possible to use 2012-07-15-wheezy-raspbian.zip, too or is there a fundamental difference?
i'm looking forward to use tinycore on the rpi.
thank you for your work, help and, at the end, your reply.
-
With the many arm platforms and their specific configurations my approach is to create a kit.
Like a remastering tool to be based on using an actual current core.gz and updating it to arm via existing known working Arm distribution.
This way we can jump start on open community development on several arm platforms. Without having to initially build all the necessary support tools and GPL compliant sources. Don't make such a commitment until you know the results would be worth the effort!
What is about a virtual environment, like http://sourceforge.net/projects/rpiqemuwindows/ ? Actually I do not have a Pi but would be interesting to play in a virtaul environment before grabbing one.
-
netnomad, I started with standard Debian and used Qemu to get Core working. Once I got my pi and could verify that root filesystem worked I then I took my notes and made some scripts to make a kit.
I did this precisely for the reason that you posted. Imagine if I had dedicated so much time to compile each and every binary component needed for Core. I would not be happy to start all over again. My methodology is too quickly prototype to see if an end result is worth the effort. And with Arm development still evolving, a kit seems to be more efficient way to get started.
Since so much work has been done over the years to whittle down Core to a minimum, I thought it would not be difficult to identify the x86 binaries and replace only those. Because I commented the scripts it should not be difficult to change the actual Arm binary replacements for an alternate Arm distribution. I am currently focused on the same method for the Allwinner A10 Mele.
I posted this early cut of picore-kit. I am hoping that the community will take advantage of the opportunity to be involved in the early development of Pi Core.
So I suggest to try Raspbian. Look at the code in setup.sh and change as needed for Raspbian's arm binaries. Post your results here.
My scripts are only a starting point, a concept, a strategy, a way to share how to get Core on Arm platforms. I am truly hoping that the community will get involved.
Once the community is satisfied with a particular kit, then the dependency Arm binaries replacements can be dropped for actual compiled from sources and we can host a complete image.
-
@bmarkus, I actually used Qemu on TinyCore to produce the root filesystem for Core on Pi. We already have all the needed extensions in the repository. I can tarball it up and send to you. I don't have Windows so Qemu on Windows is not something I can help with. It would be great if you would be willing to help.
-
Robert,
current picore runs fine on TC and WIN XP. When can we expect compiler toolchain and X?
-
hi roberts,
i adjusted your scripts and used them with the actual raspbian-image.
although i got the idea that i used them in the right way, but nevertheless the initramfs or the rootfs isn't found.
this is the last boot message:
PANIC: No init found. Try passing init= option to kernel.
Entering kbd (current=0xcb846c80, pid 1) due to Keyboard Entry
kbd>
btw, the same happens without any attached keyboard.
that's my setup:
this is on the /dev/mmcblk0p1
tc@box:~/.MNT/mmcblk0p1$ ls
arm128_start.elf cmdline.txt kernel_cutdown.img
arm192_start.elf config.txt kernel_emergency.img
arm224_start.elf issue.txt loader.bin
bootcode.bin kernel.img start.elf
as you advised i completed the cmdline.txt with nozswap:
tc@box:~/.MNT/mmcblk0p1$ cat cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait nozswap
and my second partition is filled with the tinycore-rootfs
tc@box:~/.MNT/mmcblk0p2$ ls
bin/ home/ lost+found/ proc/ sbin/ usr/
dev/ init mnt/ root/ sys/ var/
etc/ lib/ opt/ run/ tmp/
tc@box:/mnt/mmcblk0p2/etc$ cat motd
(°-
//\ Core is distributed with ABSOLUTELY NO WARRANTY.
v_/_ www.tinycorelinux.com
is there a problem with my fstab? is it o.k. that there is no root defined in fstab!?
tc@box:/mnt/mmcblk0p2/etc$ cat fstab
# /etc/fstab
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
devpts /dev/pts devpts defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
would you be so kind and give me further hints.
thank you for your help.
-
hi netnomad,
Did you compile the custom apps of busybox, rotdash, and autoscan-devices on Raspbian ?
The init failure would suggest an issue with the busybox binary.
-
When "we"get more to help in such an effort.
I will again prototype X. I have been compiling natively on arm target.
Perhaps you can help the effort via a cross-compiler on big Intel box?
-
hi roberts,
i missed your hint for compiling custom apps of busybox, rotdash, and autoscan-devices on raspbian...
and actually i have no clue what you mean ;-)
would you please be more specific that i can go ahead?
thank you for further hints.
-
Have you compiled C source code? I mean copy over the armv6 directory from picore-kit to Raspbian and use Raspbian's tools, gcc / make to re-compile the three custom apps of Core.
-
no, i didn't.
so i have to copy the armv6 directory into the home directory of raspbian
or should it be in a /src-directory somewhere in /usr or /usr/local?
-
Does not really matter where as you will need to copy back into your kit.
-
I had forgot to post a picture from picore-kit:
(http://distro.ibiblio.org/tinycorelinux/4.x/arm/armv6/piCore.jpg)
-
After an initial failure to change scripts and mount necessary files I can make a virtual file system with create.sh and setup.sh which runs fine in QEMU on TC. I increased file size to have more room for programs, changed file system from ext2 to ext4 and added a swap.
Next I tried to add GCC from Debian but still result is partial, still can't compile. Finding missing components is a slow procedure. Does someone have already a working C toolchain running on picore? Would be good to share it somehow not to reinvent the wheel.
Sharing I mean either an extended picore setup script which adds the toolchain or an image with the toolchain. In this very initial development phase it can be done regading license rules in my view and replace it step by step with own binaries.
Having a compiler toolchain I'm sure more members would do something with it.
-
If you have a pi then use the parent, i.e., Debian image on pi includes toolchain. Without a pi then try cross-compiling.
However, it appears that Raspbian ( hard float ) is more desirable. So the scripts in picore need to be updated to look for the extended paths used by hard float libraries as well as Core's three custom binaries need to be re-compiled.
However, if you don't have a pi then current Qemu in repository is not suited. Qemu needs an update to better support hard float binary emulation.
So, not sure if the effort is worth it to continue with current soft float Debian image.
Perhaps it is better if time is spent to update Qemu so others without pi can test. Need to co-ordinate with Qemu's contributor.
-
I suppose that one could compile from within Qemu using the toolchain provided with the full Debian image.
Extract Debian's rootfs to accomplish.
dd if=debian6-17-02-2012.img of=debian_rootfs skip=15769 count=3256320
Still the question is hard float versus soft.
-
Next I tried to add GCC from Debian but still result is partial, still can't compile. Finding missing components is a slow procedure. Does someone have already a working C toolchain running on picore? Would be good to share it somehow not to reinvent the wheel.
Have you looked in
http://landley.net/aboriginal/downloads/binaries/ (http://landley.net/aboriginal/downloads/binaries/)?
I could barely run something thereof due to lack of time, however I had some apparent success on my Allwinner.
I think armv6 is armhf already, but I'm not totally positive.
-
This was interesting to play with a bit, but I have to suspend it now and work on my other projects.
-
I am in final testing of first kit for generating Core running on Raspbian.
-
i'm looking forward to contribute in testing...
... hopefully you provide us some material that we can transform in a working environment.
some more hints a welcomed.
-
ATM it successfully boots and runs Core's configuration scripts.
Some utilities need to be recompiled for Core's specs.
Again, this takes an existing Raspbian SD card and together with x86 core.gz and creates a new rootfs.
Then the new rootfs overwrites the Raspbian rootfs on 2nd partition.
I can always use help with those comfortable compiling code, i.e,, use their Raspbian and compiling from sources used in Core.
Its a compile and test cycle.
-
These are good steps as I am in for BeagleBoard here and seeing that there is an effort to compile for Raspberry Pi in place. BeagleBoard is an ARM7 cortex A8 by Texas Instruments -- beagleboard.org
I will like to try tc on Beagleboard using your distro. Also I will like to attempt the cross-compile using the CodeSourcery Lite and document it.
Is it possible to cross compile from tinycore linux running on a PC? I mean using cross tools like CodeSourcery, Buildroot, Yocto, etc.., I have used CodeSourcery, buildroot and Yocto to cross compile recently. I believe they could be used for tc Linux as well since they allow you to use custorm linux kernel and external tools.
God blesses!!!
Best regards,
Sanyaade
-
Arm v7 Cortex A8 sounds more like the Allwinner than Raspberry Pi.
I have posted a prototype Allwinner image. However it is an initramfs and then layered with uBoot.
There are posted instructions to unpack in the Allwinner thread. Perhaps you could try that rootfs on your system. We have been doing both native and cross-compiles. Still early stage but the basics (Core only) seem to be working. The Allwinner effort is further along than the pi.
-
Updated picore-kit, now a single easier to use script, now posted:
http://distro.ibiblio.org/tinycorelinux/4.x/arm/armv6/
Carefully and fully read the README file.
-
Now posted the first kit (script) to turn a Raspbian bootable SD card into a Core SD card.
These are considered to be a proof-of-concept and to gauge the interest therein.
See: http://distro.ibiblio.org/tinycorelinux/4.x/arm/armv6/
Carefully and fully read the README file.
-
Thank you all for your reply.
I will look into those points raised and also the links :)
God blesses!!!
Best regards,
Sanyaade
-
The picore-kits will be going away as they were an interim step to achieving a bootable Core image using initramfs as is currently the case with x86 Core. The kits were just my attempt to have an open development process. Even though I got very little feedback they served their purpose, if only for me to better understand the task at hand. I will continue to use them (modified) so as to keep the Arm ports in sync with the x86 port.
Raspberry Pi Core will be at about the same stage of development as the Allwinner A10 Core. I will be posting it in the next couple of days. I am only focusing on Core as everything else is an extension. Hopefully some in the community will join me in this Army effort.
-
Hi roberts - I have a pi but very little time to play with it at the moment - full time job and I've just moved in with the missus which means I can't have piles of electronics all over the place, apparently that's not on.... oh to be a student again...
Like you I tried to use the Raspbian distro as a base and then strip out the basics into something that can be booted using initramfs. *Unlike* you I sort of gave up after a while because I wasn't getting very far, the thing wouldn't boot and honestly I couldn't even find the tinycore shell scripts in the repository and so ended up gettting them from an x86 ISO release and copying them over.
I'm happy to test but that's probably as much as I'll be able to do, perhaps if there's a toolchain I can begin compiling packages.
Keep up the good work.
-
You should be able to use the tool chain as provided by compiling on the Raspbian release.
-
This topic is being locked as the kits are no more.
Look for early builds of rpiCore which, as would be expected, you dd to an sdcard.
Only one partition, vfat, is used as this now runs similar to Core on x86, i.e, loads the base into ram via initramfs.