picore-kit

[roberts]

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.

[netnomad]

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.

[bmarkus]

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.

[roberts]

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.

[roberts]

@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.

[bmarkus]

Robert,

current picore runs fine on TC and WIN XP. When can we expect  compiler toolchain and X?

[netnomad]

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.

[roberts]

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.

[roberts]

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?

[netnomad]

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.

[roberts]

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.

[netnomad]

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?

[roberts]

Does not really matter where as you will need to copy back into your kit.

[roberts]

I had forgot to post a picture from picore-kit:

[bmarkus]

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.