First let me say thanks for your interest, contribution, and progress in getting Core on A10.
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!
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.
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.
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.
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.
I know of the packaging technique, as documented on j1nx's site. But not of unpacking such. If you do please share.
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
tail -c +65 uCore | gunzip | sudo cpio -idshould give the rootfs in pwd.
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
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.
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.
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.
Welcome
FAQ
Downloads
Wiki
