Towards Microcore on Allwinner A10

[karlmw]

Did you build the kernel using TinyCore?  (I mean building inside the x86 version of TinyCore)

I have a TinyCore VM (running under qemu) which I use for building x86 TinyCore packages, and find that it is the easiest way for me to maintain a stable environment to compile in regardless of changes on my main machine.  Qemu (running on windows) hosting the TinyCore VM works well for this because it's a completely portable setup that I can backup or make copies of and it still works just fine.

I'd like to be able to use a TinyCore VM to build modules for the mini-x - I really need to build a wifi module (8192cu) so that the mini-x can be useful for something (no RJ45 ethernet on the mini-x - only wifi).

Do you have any tips for the build environment?  I've only ever compiled one kernel module (many years ago) but I seem to recall that for compiling the modules you need exactly the same compile environment as the kernel had.    Thanks  :-)

[roberts]

Yes. I use Tiny Core to do everything!
I am using Code Sourcery as my cross compiler.
I have built both rpi and a10 kernels using only Tiny Core and Code Sourcery.

You will need the following tcz extensions loaded:
bash.tcz
util-linux.tcz
perl5.tcz
ncurses.tcz

1. Download Code Sourcery
http://www.codesourcery.com/sgpp/lite/arm/portal/package/7851/public/arm-none-linux-gnueabi/arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-iinux-gnu.tar.bz2

2, Untar it on a persistent device, e.g., /mnt/sdb1
    It will create a directory called arm-2010.09

3. mkdir -p /mnt/sdb1/mele/modules  and cd /mnt/sdb1/mele
Download the kernel and defconfig from our armv7 directory and untar and bunzip the defconfig
This will create an amery-linux-allwinner-21eeb80 directory, cd into it.

4. cp ../mbc_defconfig arch/arm/configs

5. Setup exports for cross compile
    export PATH="$PATH":/mnt/sdb1/arm-2010.09/bin
    export ARCH=arm
    export CROSS_COMPILE=/mnt/sdb1/arm-2010.09/bin/arm-none-linux-gnueabi-

6. make mbc_defconfig

7. make menuconfig

8. make uImage && make modules

9. make modules_install INSTALL_MOD_PATH=/mnt/sdb1/mele/modules

Your modules will be in /mnt/sdb1/mele/modules
The kernel is in arch/arm/boot

HTH

[karlmw]

Thanks for the detailed instructions. 
Unfortunately, the codecourcery link does not work for me ("The page you requested does not exist.")

It appears that codesourcery are now only offering 30-day evaluation copies.

[roberts]

Try this:
http://www.codesourcery.com/sgpp/lite/arm/portal/package7853/public/arm-none-linux-gnueabi/arm-2010.09-50-arm-none-linux-gnueabi.bin

It appears to be self-extracting offering the same version.

[roberts]

Another option is to build natively on mini-x. Use one of the full linux distros mount a pendrive, place download files and directories on pendrive and hopelly perhaps overnight it will complete the compile!

[roberts]

Karl, I will post my modules directory. If all you want is 8192 its in there!
Wait while I upload if.

....

Done: Look for allwinner-sunxi-v3.0.39-modules.tgz in the armv7 directory.

[roberts]

New cut posted. Fixed some links and added missing library.
http://distro.ibiblio.org/tinycorelinux/4.x/arm/armv7/
Now passes the links.tcz test. I can browser on allwinner a10 with links.tcz

[karlmw]

Thanks for the modules!

Using brute force and quite a lot of ignorance, I was able to get wifi working last night.  I used the 8192cu module you provided, with wireless-tools and wpa_supplicant from Debian Wheezy armhf.

Over the next week I will try to get SSH working, along with documenting what I've done (last night was a quick hack job to see if it would work at all).  Being able to connect remotely will make the mini-x enormously easier for me to play with.  My goal is to setup mpd (Music Player Daemon) to replace my existing HP t5710 (which is running mpd on tinycore).

Is there a working mechanism for persistency, yet?  All I need is something to run a script at boot time.  If there is no existing method, I'll have a go at a simple remaster and add some code to bootlocal.sh to find and call my own script (which will then get wifi/ssh going).

Is your links.tcz posted anywhere?  I did not see it in the tcz directory where you have posted the a10core images.

[roberts]

In order to begin testing functionality I need at least one extension with some dependencies.
A kind of chicken versus egg situation. To that end I began to extend a tool, deb2tcz to automate the creation of complex extensions.
I posted about it in the raspberrypi section.

Knowing that it is a huge task of compiling and building extensions,
I have purposely made raspbianCore library compatible with Raspbian.

To that end I have been working on and testing dynamically creating
tczs directly from Raspbian repositories. If this is successful then
it will greatly lessen the need to build/compile hundreds of extensions.
So far initial tests look promising, example: Links browser and its dependencies.
Auto created by entering only links.

My goal is to easily and transparently gain access to some of the 40,000 debs
which the user can select. They, of course, become tczs and thus gain
the Core advantage of pristine boot, onboot, and ondemand features.
Our ibibio arm tcz repository might then only need to host custom extensions not
available in the Raspbian repositories.

So I would hold off building extensions until I accomplish a first
milestone of this tool. Then evaluate its performance and capabilities.

Of course, I am not going to abandon the community built extensions.
The support code for such will remain intact.
The new tool will be just another option. Another tool that the user may or may not
elect to use.

So links.tcz and links.tcz.dep were auto-generated. I am hoping that wireless-tools and
wpa-supplicant will also be as easy. Although I don't think that my program will be a
panacea. It will hopefully be a sometimes useful option.

As for persistence, at the moment I am using a pendrive. It is recognized and is easily available via
the standard mount /mnt/sda1. You can backup and restore from it, you can tce-setdrive it.
You can tce-load -i links and it will use the link /etc/sysconfig/tcedir. All that seems to be working.

However, I have not yet looked into how to specify boot commands. I believe it will be in boot.scr
boot.src is another allwinner "compiled" file. Therefore another obstacle to overcome. We need to
be able to specify a waitusb command inorder to test onboot functionality.

Trying to do both allwinner and raspberrypi in parallel is also quite trying as their boot methods are
quiet different. Albeit quite interesting.

[karlmw]

Making use of existing repositories sounds like a fine idea to me, whether it provides only a stepping stone or becomes a preferred method of installing extensions.  While we have the option of building our own, being able to use existing packages enriches our options.

Is the links.tcz you have used on A10 derived from the Raspbian repo or the Debian repo?  I know from my own testing that the Debian Wheezy armhf binaries work, but I was not sure if code compiled for raspberrypi was compatible with A10 or not.  It's not 100% clear to me whether your quote from the raspberrypi section was merely illustrative of the concept, or specific of the detail.

Given the inconvenience of editing/compiling boot.scr, my thoughts on persistency (in the absence of something better) tend toward being able to specify a script (on the boot drive) which will provide additional boot scripting. 
eg.  my first hack (for my own testing) will be to remaster an a10core image with a bootsync.sh which searches for a flashdrive with a specified label, mounts it, searches it for a script with a specified name (probably just bootsync.sh in the flashdrive root to start with) and passes control to it.  I'd probably also get bootlocal.sh to look for a bootlocal.sh on the flashdrive.

This approach will give me enough to play with so I can have the mini-x boot and get itself online without me needing keyboard/monitor.
 
In practice, I'm probably not going to search for a flashdrive - I'll probably just mount mmcblk0 (the micro-sd card) and look for a bootsync.sh there.  Should be quick/easy/reliable.  In the long term, I'd like kernel commandline options to specify additional bootsync/bootlocal files - that way boot.scr only needs to be edited once, and thereafter it's easy to fiddle with a text file instead.

My other thought is for options which would normally be passed on the kernel commandline.  I wonder if instead it would be possible to pass a kernel commandline option which specified a file to parse for extra options as if tinycore had received them on the kernel commandline.  The file spec could be much like the spec for current x86 TinyCore persistency,

eg. options=LABEL=MyFlashDriveLabel/path/to/file/with/boot_options.txt
   which would look for the specified file on a device labelled as MyFlashDriveLabel

or options=BOOT=/path/to/file/with/boot_options.txt
   which would look on the device we booted from rather than specifying by label (I don't know if the kernel knows what its boot device was, though)

I don't know if this is practical or not, or even useful - they're just some things I was thinking about.  There's probably a simpler way to do it - eg. just edit boot.scr, compile it, and stop wasting time dreaming up complexities  :-)

[roberts]

Karl, The script that I have started is generic. Porint it at a Debian repository,i.e., your closest mirror, as would be the case with a Debian install. So no, not Raspbian specific. links.tcz + dependency tczs are from Debain Wheezy armv7h. Like I said I have not yet had a chance to consider boot.scr possibilities yet. Much to do, but progress is certainly happening. At the moment my script is 3/4 done, some parts I am still doing manually, but the concepts are all there. I will post it as soon as I reach first milestone. Both A10 and Raspberry Pi will benefit, in fact, any other port of Core to any other Arm device, which Debian has already been ported should benefit as well. Keep posting about your progress as well.

[roberts]

Given the fact that these Allwinner devices currently boot from a know source, I have automated the update of the boot codes.

Presently we have the typical showbootcodes command. I now have an updbootcodes command which based on the environment variable EDITOR allows easy editing of extra boot commands. We trust users to be able to edit grub/menu.lst, syslinux.conf, etc. So too, I have transparently scripted the unpacking of boot.scr dumping the contents into an editor and upon exit of editor, dynamically compile a new boot.scr. Update occurs only  if no detectable errors. Then reboot to effect.

So now...

I am using a pendrive for my backup and extensions. It is recognized and is easily available via
the standard mount /mnt/sda1. You can backup and restore from it, you can tce-setdrive it.
You can tce-load -i links and it will use the link /etc/sysconfig/tcedir. All that seems to be working.

And now you can easily specify the usual boot commands by using the updbootcodes program e.g., waitusb=5:LABEL=melepen tce=LABEL=melepen tz=PST+8PDT,M3.2.0/2,M11.1.0/2
 
onboot works as expected and automatic restore work as expected!

I will do some more testing and then post an updated image with this new updbootcodes command.

[roberts]

Now posted 20120917 image. See: http://distro.ibiblio.org/tinycorelinux/4.x/armv7/

This has the new updbootcodes.
This allows easy editing of the systems's boot codes file to add Core specific boot codes.

[roberts]

Now posted 20120920 image. See: http://distro.ibiblio.org/tinycorelinux/4.x/armv7/
Fixed more library issues.

[karlmw]

I'm running the 20120920 image on my mini-x.
I've added the kernel modules posted on ibiblio, along with some bodgy scripting and a bunch of Debian Wheezy armhf packages.
So, now I can ssh into the mini-x via wifi - a great success  :-)