dCore Import Debian Packages to Mountable SCE extensions > Allwinner A10
Towards Microcore on Allwinner A10
caminati:
--- Quote from: roberts on August 20, 2012, 10:30:51 AM ---uCore now working.
Used the image file. Copied the boot.scr from first attempt together with uCore to first partition. Formatted the 2nd partition and left blank.
Boots and is working fine.
--- End quote ---
Nice! That uCore is still not completely functional, mainly due to blkid missing, but this is nice to hear.
I think the presence of 2nd partition is irrelevant, by the way.
From now on, I will use image files :)
As soon as I have time, I will try to get to beta quality (except for zcache, again).
Then on to toolchain: if you have some tcz already done, I would like to try that.
Otherwise, I've my eyes set on aboriginal, which seems to provide binary tarballs with nice toolchains for lazy people :)
caminati:
If the upload goes well, you will find first beta image on my homepage.
Check README for usage.
Notes:
Very few kernel modules and binaries, hopefully not needed during boot, missing.
I redirected verbose tc-config output to /var/log/tc-config: it would be useful if Core people checked that to assess about thinks going well.
tce-load et others do not work due to absence of builtin getopts.
Redirecting to busybox getopt does not work, however changing #!/bin/sh to #!/bin/ash should do it, if I included the right busybox.
Sorry, I am not totally sure of statement above, since busybox versioning is a mess, as is u-boot one: indeed I probably included the wrong version in previous releases, so yes, Robert's failure to boot was probably my fault.
This time I checked the upladed version myself, should work.
roberts:
First let me say thanks for your interest, contribution, and progress in getting Core on A10.
Your latest build boots fine too. However I have some concerns about the direction this is going.
Obviously bterm is the trick to get Core on A10 without it, as the other distros have done, is to have full X.
Your approach is to have already packaged up Core (initramfs) which makes it more difficult to be open development.
My approach, as I have stated was to have an open rootfs, then later package it up. It eliminates extra steps during development cycles. I know of the packaging technique, as documented on j1nx's site. But not of unpacking such. If you do please share.
Do you have the source and makefiles for the binaries that you are distributing or are you basing this on say the linaro builds?
I am most interested in the source and makefile for bterm
Also it would be great if our target is the same. So if you have sources then perhaps hosting them here will make for a more open devlopment environment.
Otherwise I can only test your packaged core while continuing in parallel development.
caminati:
--- Quote from: roberts on August 23, 2012, 01:29:04 PM ---First let me say thanks for your interest, contribution, and progress in getting Core on A10.
--- End quote ---
I'm doing that because I want my hardware to run the software I like.
Sheer utility apart, hence, I'm doing that to celebrate how good what you and Core team created is: thanks for that, folks!
--- Quote from: roberts on August 23, 2012, 01:29:04 PM ---Your latest build boots fine too. However I have some concerns about the direction this is going.
Obviously bterm is the trick to get Core on A10 without it, as the other distros have done, is to have full X.
--- End quote ---
If you mean that a possible bterm crash could make the machine unreachable, I am a bit concerned about that, too.
We're relying on some obscure piece of code as the only means of video output.
However, it is a tiny piece of code, while any X server is much bigger, and hence much more likely to crash.
The good news is that it never crashed here, and even under some trivial crash tests (e.g. killing it while reading /dev/ptmx) it behaved itself.
By the way, any ideas for meaner tests on bterm are welcome.
Of course, I would prefer fbcon support in mainline kernel, even only to be a bit more confident about stability.
--- Quote from: roberts on August 23, 2012, 01:29:04 PM ---Your approach is to have already packaged up Core (initramfs) which makes it more difficult to be open development.
My approach, as I have stated was to have an open rootfs, then later package it up. It eliminates extra steps during development cycles.
--- End quote ---
At first stages, I used standard rootfs (no initramfs). Later, with some stability achieved, I stuck with initramfs; the main reason is that I want to stay as close as possible to original core.gz x86 initramfs.
Indeed, I preliminarily repackaged your core.gz in nine separate rootfs: binaries, scripts, symlinks, and so on, which is probably not much scriptable (but may desirable for its own sake).
Then I overlaid selected binaries and patches to some of those split rootfs and repackaged, which is quite quick and scriptable.
A second reason is that there is an annoying difference between working with and without initramfs: in the latter former case /dev must be pre-populated, I don't know why exactly.
So I had to avoid switching between the two modes, and stuck with initramfs.
--- Quote from: roberts on August 23, 2012, 01:29:04 PM ---I know of the packaging technique, as documented on j1nx's site. But not of unpacking such. If you do please share.
--- End quote ---
Sure: the only constructive difference between uCore and core.gz is the final mkimage pass, which merely prepends a 64-byte header for u-boot purposes (I think this has to do with u-boot having to deal with a filesystem without having an OS running).
Bottom line: doing something like
--- Code: ---tail -c +65 uCore | gunzip | sudo cpio -id
--- End code ---
should give the rootfs in pwd.
--- Quote from: roberts on August 23, 2012, 01:29:04 PM ---Do you have the source and makefiles for the binaries that you are distributing or are you basing this on say the linaro builds?
I am most interested in the source and makefile for bterm
--- End quote ---
This is a patchwork. busybox binary is the one distributed on its homepage, with a second version coming from aboriginal for some applets (notably sh).
bterm binary comes from debian.
I managed to build it on x86 (with both manual patches and debian's diff, which I don't like, however), but I have to set up some toolchain before having and TESTING it on ARM.
Alternatively, I could free a mmc and setup some ready-made Allwinner Debian to straight compile it.
The rest is either from debian or compiled on ARM Debian some weeks ago, before I needed the mmc for other uses.
--- Quote from: roberts on August 23, 2012, 01:29:04 PM ---Also it would be great if our target is the same. So if you have sources then perhaps hosting them here will make for a more open devlopment environment.
Otherwise I can only test your packaged core while continuing in parallel development.
--- End quote ---
I would strongly prefer an open and collaborative work, and would gladly provide any source code.
As from above, the sources are all there, the problem is that in many cases I'm using the corresponding binaries compiled by someone else (i.e., Debian maintainers), and that I did that manually, without tidy scripting as you did in your picore.
In the future, I could set up Debian on my tablet, and reproduce the binaries by myself, if you think this would be preferable. In a second moment, I could do the same from ARM Micro Core by using some toolchain.
For the time being, I can supply:
* kernel config
* core.gz split into the nine parts as from above
* a script to get from the split core.gz and other binaries to uCore
or whatever you deem worth it.
roberts:
Thanks, I figured out how to get into Ucore by using dd.
I did notice that your busybox is not compiled from our config as some applets are missing and other are configured differently, e.g.,tar.
I usually start with natively comping our busybox, e.g. as on the raspberry pi, as it is the center piece of Core then start from there.
Today I have setup a headless Arm development machine for compiles. Now that I am able to get to the roofs I can better look around and hopefully start adding some missing pieces.
Sorry, If I sounded like I was complaining about bterm. That is a great find!
I suppose we can hold off hosting until compile from sources becomes available or unless your resources (serfver) becomes to taxed.
Allwinner is a challenging platform and you have done an awesome job!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version