[Interest] [linux] QtCore behaviour w/o system init

[Jason H]

I come from the embedded space as well, and although I don't have that 1s requirement, I would try it as obly a slightly modified boot image. My laptop (AMD A6) boots full Mint linux in 3-4s with a SSD. When booting linux for your application, the real lag is the ram speed. But you didn't mention any hardware specs...

I would try booting a minimal kernel that you compiled yourself ('make xmenuconfig'), compiling Qt statically into your application (This will result in a several MB binary which I would put into your initram fs. I think the most time spent will be just reading the image. 

I personally, would use the microprocessor approach and put it on a bus that linux supports (I^2C?) and control the micro from linux after the system is up. But I leads me to ask, how are they controlling/monitoring the product? LCD and a few buttons? It might be better to create a miniature C program for the control until you can get Qt loaded and running, then kill that process and have Qt take over. Or, add a socket to the program to take commands from Qt after it's up.




________________________________
 From: Christian Gagneraud <chgans at gna.org>
To: interest at qt-project.org
Sent: Saturday, September 14, 2013 4:29 AM
Subject: [Interest] [linux] QtCore behaviour w/o system init
 

Hi there,

For an embedded project I'm working on, we have a need to allow the end 
user to control/monitor a subset of the product as fast as possible 
after power on (ideally less than 1s).
To do this task, the first idea that came in was to use a dedicated 
micro-controller to do this job (can boot in few ms!), the problem was 
that the hardware would need to be shared with the application processor 
once the system is fully booted (and plenty of other annoyances from a 
SW point of view). So the second idea was to handle this task in the 
boot loader itself, this one is better, but it means no kernel, np 
userspace, no libs, ... So lot of things will have to be re-invented 
(again, annoyances from a SW point of view).
Now, I would like to explore a 3rd idea: boot to qt using a strip down 
XIP linux kernel and "no rootfs", and then when requested, use kexec to 
boot to the full kernel/rootfs for more advanced tasks.I've seen this 
kind of approach in action, and it's really fast to boot (AFAIR ca. 1s 
on an ARM9 at 200Mhz with init=/bin/sh, which means no Qt).

To start with, I would like to know how QtCore would behave with no 
system initialisation at all: the init process is the Qt based app 
statically linked (or not, see below), no /dev (or a bare static one if 
really needed), no /sys, no /var mounted, no network setup, no udev, no 
syslog, no D-BUS, no nothing! Well, The only thing available is / 
mounted by the kernel.

The second question is about static linkage, is it possible to have a Qt 
based application that is entirely statically linked? More precisely, 
what about qt when it comes to runtime plugins? Basically, the idea is 
to get rid of the full rootfs, which means no SO objects whatsoever. At 
the same time this question revolve around getting rid of useless (in 
this context) dependencies of libQtCore too (glib, and the likes but 
stuff like network, connectivity as well).
I've seen the "-no-feature-<feature>" of Qt's ./configure and had a look 
at the associated qtbase/src/corelib/global/qfeatures.txt, but I never 
really used that, thought, It looks to me that Qt can be stripped down 
to the bare minimum.

If anyone has suggestions, comments or feedback on achieving this kind 
of goal, please feel free to share them!

Best regards,
Chris
_______________________________________________
Interest mailing list
Interest at qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130914/2781c469/attachment.html>