Competent help needed for Core on ARM Allwinner

[caminati]

Background
Lots of talking about Allwinner A1X processors, which are conquering the embedded world right now (512Mb tablet for 60usd), and are the heart of some very attractive mini PCs (Mele A1000, Mk802, Ak802, each for 60 usd, too).

Substantial progress has been done with running linux on it: there are Debian, Ubuntu, Linaro, Fedora and possibly other distros turnkey-ready for any Allwinner-based machine.
I myself, with my not-so-advanced knowledge, have been able to compile my own kernel.

The problem with Core
What is missing to have our favourite distro on it? After some hands-on experimenting, I dare to say that the single fundamental point is the lack of support for a text-based virtual console emulation.
This implies having to compile, set up and run Xorg server in order to have any output (unless you own some dedicated hardware hack).
Of course, this breaks the modular-minimalistic spirit of Core, and hinders further development.

Technical details
So I am here advertising the problem, in the hope some competent reader gets interested.
Technically, the issue is that the fbcon linux device needs maintenance (note that fbdev is working, to the point you can run Xorg on it, and that you can't base textual virtual consoles on the old vgacon, because I understand that (S)vga is guaranteed only on x86 PC architecture (?) ).
More specifically,

the fb driver (disp) lacks of several callbacks and tables needed by fbcon (sic),

as vague as it sounds.
Details are available at
https://github.com/amery/linux-allwinner/issues/6 ,
where allwinner kernel sources are hosted, and at
http://ibot.rikers.org/%23arm-netbook/20120525.html.gz.

Solving this issue would be a big leap forward.

[roberts]

I am aware and following developments on Allwinner A1x. This is my current assessment.

The framebuffer console is still not working and is a known issue.
You can compile a kernel but fbcon crashes!
See: https://github.com/amery/linux-allwinner/issues/6

Second hurdle is initramfs which is a part of Core architecture.
See: http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-July/004970.html

While it is true that many traditional Linux distros are ported, i.e., take existing original Ubuntu and switch window manager or DE, then add custom scripts and remove and add selected apps is not too difficult a task. However Tiny Core is not a traditional distro with its unique architecture.

Still too Allwinner has its configuration files are compiled into binary making it not so easy to specify memory or even resolution. See miniand.com forums for the various u-boot and evb.bin binaries and the issues users are having when an image it released to 1GB and you have only 512 or the image is for a higher resolution and your hdmi can only do 720.

I don't mind discussing such issues but I feel Allwinner is not quite ready unless Tiny Core changes to go traditional.

Then there is Raspberry PI. The good is plain text files for configuration and X is not required. The bad is weak processor and limited memory. Also reports of SD cards being incompatible.

Most users are using VGA monitors. The mentioned platforms typically require a hdmi video device.

Then on any platform is the hard float versus not issue. All of this needs to be addressed before  committing. Even then we will need a community to build all new extensions and resources both from the Team to process them and resources available to host them.

Linaro is also interesting. Here is a video of their assessment and goals for their project.
http://www.linux-arm.info/index.php/167-ubuntu-on-arm-improvemrnts-and-optimations-done-linaro

For Tiny Core to go arm at this early stage would be quite different than on x86. But then perhaps that would not be a bad thing?

[curaga]

Yep, any image tends to be per-device. Just providing the binaries and leaving the bootloader setup to the users would work for the more advanced group, but wouldn't be that popular IMHO.

For the Allwinner, fbcon would be essential, but I don't think we have that kind of kernel expertise around here. Always happy to be proven wrong though

BTW, the rpi folks announced that production is up and order restrictions no longer in place. Robert, have you received yours yet?

[roberts]

Yes. Finally received mine. Very picky about booting from sdcard. Only one out of four of my sdcards would boot. After boot only 190MB of ram for linux use. It is slow. Each hard float image I have tried so far hangs after a short period. The armel version does not hang. Now if only the easy configuration and fbcon of the pi could be available on the A10 then things would be looking good.
I will still try to hack something on the pi as at least I have a console without having to resort to soldering and using ttl-usb and minicom on another device for such on the A10 devices.

[caminati]

I don't mind discussing such issues but I feel Allwinner is not quite ready unless Tiny Core changes to go traditional.

Nobody here would want that, I guess! ;) On the contrary, having Core on such hardware to work would be such a relief. Currently, you need to download hundreds of megabytes binary to get a minimal working Allwinner machine; now that I am accustomed to Core, this sucks. =)
However, of all the issue Robert mentions, the one with fbcon is the biggest one, in the sense that the others can be solved with a per-device approach, as Curaga suggests, and require less expertise.
This of course wouldn't prove practical for the common end-user, but would allow the willing user to at least have his favorite OS on his favorite hardware, tinker, and possibly work on the remaining issues.

Most users are using VGA monitors. The mentioned platforms typically require a hdmi video device.

Except for the Mele.
I also recall seing linux images for DE-15 (I find that talking of (S)VGA on ARM platform is confusing, see my first post) output on Miniand.

Linaro is also interesting. Here is a video of their assessment and goals for their project.
http://www.linux-arm.info/index.php/167-ubuntu-on-arm-improvemrnts-and-optimations-done-linaro

Thanks for the link.

For the Allwinner, fbcon would be essential, but I don't think we have that kind of kernel expertise around here. Always happy to be proven wrong though

If anybody reading has in mind any possible community or individual worth being contacted about that, I could try asking :)

[roberts]

FWIW, As I posted on Raspberry Pi, once I establish a full Tiny Core, think full X, on Pi then I will try to  update arm binaries and focus on Allwinner.  Much to learn, much to do.

[caminati]

Much to learn, much to do.

I quote that vehemently :)
At the moment, I am assessing workarounds to the fbcon issue, leveraging on Xfbdev, and some alternative minimal framebuffer software (fbterm, fbpad,; see e.g. http://forum.tinycorelinux.net/index.php?topic=12934.0 and http://kmandla.wordpress.com/2010/04/16/a-quick-look-at-framebuffer-applications/).
However, I am not sure whether they need fbcon or not, and I can't proceed due my failure to make u-boot's script work to pass alternative boot parameters.

Whining apart, I have some questions:

• For testing purpose, I am tampering with core.gz: I split it into three filesystems: binaries, symlinks and all the rest (config files, scripts, etc...). I am trying to trim the first before recompiling it for allwinner. For example, I think pcmcia stuff can be removed, along with many /lib/modules contents. Have you any advice about that?
  I am also interested in what busybox applets can be cut, since there is a precompiled version which I could use, and I want to know if it could work for testing.
  
• Also for testing, it would probably be more comfortable to have all the remaining binaries statically compiled. Any foreseeable adverse effect?
  

Thanks!

[curaga]

Also for testing, it would probably be more comfortable to have all the remaining binaries statically compiled. Any foreseeable adverse effect?

Hugely larger binaries and RAM use

[caminati]

Also for testing, it would probably be more comfortable to have all the remaining binaries statically compiled. Any foreseeable adverse effect?

Hugely larger binaries and RAM use

I am very interested in this diatribe; I hate complexity added by dynamic linking, but I have no concrete data about ram usage. Here this downside is debunked:
http://harmful.cat-v.org/software/dynamic-linking/

So: how much more size and ram usage, actually?

Anyway, static compiling would be just to have a quickly available testing barebone os in my case.

[curaga]

That link only lists the fact that binaries share all shareable data with copies of themselves. So you ran two copies of foo, they share the static lib in them in RAM. The statically linked bin is still huge on disk.

But if you have apps foo and bar running, both statically linked against libc, you have two copies of libc in RAM. Given it's ~500kb minimum to statically link glibc...