Hi Jason,
On 09/15/2013 02:18 AM, Jason H wrote:
> 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...
Actually, I don't k now yet, but right know a good candidate for this
particular project is the SAMA5D3 by Atmel (the only Cortex A5 on the
market) [1], other candidates on the radar are TI AM35 (beaglebone) or
43 (?) and Freescale i.mx6 to name a few. I have a very, very strong
power consumption requirement.
I don't have access to SSD but I will likely only have access to "raw"
NAND flah.
>
> 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.
The idea is to get rid of the initram fs, it takes time to the
bootloader to load it, the XIP kernel (eXecute In Place) is there too to
help reduce load time, as the bootloader doesn't even have to load the
kernel.
I do agree that it will have to be balanced: NAND execution/access time
(read: read time) vs the speed of loading the same quantity of data from
NAND to RAM (likely SDDR2, maybe SDDR3) + RAM execution/access time.
>
> 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.
Yes, I've been thinking about the uc approach, but I don't like the
"write it 3 times" burden:
1. UC
2. UC to Qt (likely serial port)
3. Qt
Now, the "C" approach: write it 2 times
What about the "write it one time"? OK more "embedded OS" work, but less
"C++/Qt" work, what's the best trade off? ....
It is about talking on i2c (and maybe "proprietary over GPIO"), it is
about HMI (LCD (TBD: from 2 lines of text to small QVGA, who knows?) +
keypad (certainly capacitive PCB keys, but maybe not!)), battery
management and few other things as well (unclear to me so far).
So basically, I would feel more comfortable relying on GNU/Linux than on
u-boot or any other "bare metal" solution.
And I would like to achieve that in 1s ideally, maybe 2 is still OK. I
don't know yet.
Hence the need for a "bare minimal" Qt on "Bare minimal" Linux or "Boot
to Qt" as Digia would name it...
Best regards,
Chris
>
>
>
> ------------------------------------------------------------------------
> *From:* Christian Gagneraud <chg...@gna.org>
> *To:* interest@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@200Mhz <mailto:ARM9@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@qt-project.org <mailto:Interest@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
[1] http://www.atmel.com/products/microcontrollers/arm/sama5d3.aspx
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
