dCore Import Debian Packages to Mountable SCE extensions > Allwinner A10
Towards Microcore on Allwinner A10
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.
--- Quote ---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.
--- End quote ---
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 :-)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version