[RFC] Qi Bootmenu
|
|
| 1 2 |
Marc Andre Tanner
|
Hi all,
I have been lurking around on various openmoko mailing lists for quite some time (about 1.5 years) but so far I didn't have the time to actually contribute anything useful because of study and work related activities. However during the last few days I actually had some time to waste. I therefore looked around for possible projects and found the boot menu thingy which interested me for quite some time because it involves various different system parts. I have seen in the mailing list archives that some people have actually already started to work on projects[0] with similar goals but as far as I know they weren't really finished and/or customized for the Freerunner. The closest thing to a working solution is probably kexecboot[1]. So here are my random thoughts on the subject, comments are appreciated. Goals ===== - The user should be able to select which image to boot from (surprised heh ;) - The image could also provide a minimal system rescue environment that is a sshd server which allows remote access to fix certain things. - In order for this to be useful it needs to be fast. Nobody wants to wait 10+ seconds just to select which image to boot. Speed is therefore the most important factor. Overview ======== - The whole system could be packaged into an initramfs - Ideally I would like to store the boot menu image in NAND flash. This would ensure that it is always around and different SD based images could be booted with it. The boot sequence would look something like this: - Bootloader (Qi) loads minimal kernel - kernel extracts initramfs /init is executed - application scans for system images on SD card, presents boot menu - selected kernel is started via kexec Bootloader (Qi) =============== - I would like to change the default boot sequence to first look for the special bootmenu image in the kernel NAND flash partition, if this is not found the boot sequence should proceed with the SD card. The user can of course still use the hardware buttons to skip the NAND boot and by pass the bootmenu system. The NAND kernel partition is 8MB large so we need to fit the kernel + initramfs in there. Kernel ====== - optimized for size just the absolutely necessary tings should be compiled in. The gta02_micro_defconfig will be starting point for this. Is it still up to date/maintained? - compress? Recent kernels can be compressed using LZMA Question is if this would actually speed up anything? Answer depends on where the bottleneck is in data throughput or computing power. What is the expected data transfer rate from NAND flash? - disable console output completely Userland ======== - uClibc - stripped down busybox - kexec-tools They only support zImages however distros ship uImages so we would either have to strip off the uImage header which is probably slow or add uImage support to kexec-tools. - dropbear sshd - bootmenu application (see next section) Bootmenu application ==================== - should be something like kexecboot, however It should be finger friendly. - functionality should be something like this (taken from kexecboot): - read available filesystems from /proc/filesystems - read available partitions from /proc/partitions - try to mount each partition, search for zImage in /boot - present menu - kexec selected kernel - GUI based on elementary with framebuffer support? In theory this would be the best solution because we would use the same technology as in a normal system just with a different backend. This should ensure that it's actually finger friendly. Although text entry remains a problem because the illume keyboard can't be used. But I hope that text entry won't be necessary anyway (no kernel command line changes through the GUI, sorry ;) In practice I don't know how mature the framebuffer backend actually is and it has quite a few dependcies[2]: * eina * eet o zlib o libjpeg * evas o freetype * ecore o ecore-file o ecore-evas o ecore-input o ecore-job o ecore-txt o libiconv (functionality can be provided by uClibc) o tslib * edje o embryo o lua * libpng I have cross compiled all this and without any special optimisation (I just disabled everything in ./configure which seemed not critical) the whole system is about 6-7MB large this is without the kernel. I am not familiar with the EFL code base but what I have seen so far seems like it isn't really optimized for size. So there could be some potential although it would require some work and upstream approval. Maybe the idea to use elementary is overkill but what are the alternatives? Proof of Concept ================ As a proof of concept I started to write a simple shell script (well in the beginning it was simple in the meantime it evolved in kind of mini build system, maybe something like OpenWRT could be used but I wanted a simple solution where I actually understand what's going on) which downloads and cross compiles everything with an uclibc based toolchain. So far I have cross compiled all the components mentioned in this post the result is about 6-7MB large. I then tried to run the elementary dialog application from the elementary wiki page[3] in a chrooted system and this works (although there seems to be a problem with the touchscreen which doesn't quite work right and sometimes even causes a segfault). Another issue is that I currently don't get any console output when booting from flash with Qi. Although I've added loglevel=8 to Qi's kernel parameters and recompiled+reflashed. Something with the init script and/or missing device nodes might be the problem. If you want to help then download the scripts and read the README file of the source tarball. http://www.brain-dump.org/tmp/qi-bootmenu-system/qi-bootmenu-system.tar.bz2 Once you have a rootfs.tar.gz file generated (after ./build.sh && ./initramfs.sh && ./package.sh) copy it over to your Freerunner. Bind mount /proc and /dev to the corresponding directories and try it out: mkdir rootfs tar -C rootfs -xzf rootfs.tar.gz mount -t proc /proc rootfs/proc mount -o bind /dev rootfs/dev chroot rootfs /usr/bin/ash export ELM_ENGINE=fb export ELM_FONT_PATH=/usr/share/fonts dialog "Hello world, works?" My current plan is to fix the initramfs console output (ideas what might be wrong?). Next step is to launch the elementary dialog app from the init script. Then shrink/optimize everything until the boot time is acceptable (or give up if we don't reach that point). And only then start to program the elementary based kexecboot replacement. This would be my first EFL application which means I will have to do some research first. Comments and/or contributions are welcome and appreciated. Happy Hacking, Marc [0] http://thread.gmane.org/gmane.comp.handhelds.openmoko.devel/2011 [1] http://git.linuxtogo.org/?p=groups/kexecboot/kexecboot.git [2] http://www.brain-dump.org/blog/entry/132/On_the_way_towards_a_minimal_elementary_based_boot_system [3] http://trac.enlightenment.org/e/wiki/Elementary -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
Sander van Grieken
|
On Thursday 08 October 2009 22:50:00 Marc Andre Tanner wrote:
> Goals > ===== > > - The user should be able to select which image to boot from > (surprised heh ;) I like this idea. Right now the U-boot menu is fixed and not easy to change, but with this idea the available images can be dynamically scanned, and also the kernel command line can be moved from the u-boot environment to the image itself, in a file or somesuch. You can even define multiple kernel command lines and show them as a sub-option to an image, e.g. to be able to select verbose logging when needed. > - The image could also provide a minimal system rescue environment > that is a sshd server which allows remote access to fix certain > things. Yep, nice, that would free the flash partition I keep for this. > - GUI based on elementary with framebuffer support? > > In theory this would be the best solution because we would > use the same technology as in a normal system just with a > different backend. This should ensure that it's actually > finger friendly. Although text entry remains a problem > because the illume keyboard can't be used. But I hope that > text entry won't be necessary anyway (no kernel command line > changes through the GUI, sorry ;) In practice I don't know > how mature the framebuffer backend actually is and it has > quite a few dependcies[2]: > > * eina > * eet > o zlib > o libjpeg > * evas > o freetype > * ecore > o ecore-file > o ecore-evas > o ecore-input > o ecore-job > o ecore-txt > o libiconv (functionality can be provided by uClibc) > o tslib > * edje > o embryo > o lua > * libpng > > I have cross compiled all this and without any special optimisation > (I just disabled everything in ./configure which seemed not critical) > the whole system is about 6-7MB large this is without the kernel. > > I am not familiar with the EFL code base but what I have seen > so far seems like it isn't really optimized for size. So there could > be some potential although it would require some work and upstream > approval. > > Maybe the idea to use elementary is overkill but what are the > alternatives? Maybe just use evas, ecore and libpng (and their deps). You'd then have to do the whole GUI programmatically, because you'd only have a canvas and will have to do some more housekeeping yourself, but how fancy do you want a bootselector to be? :) An alternative would be to look for a really minimal graphical toolkit that even has a smaller memory footprint than E. Also compile the bunch above statically, It'll show in startup speed. > Comments and/or contributions are welcome and appreciated. There you have it :) grtz, Sander _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
Werner Almesberger
|
In reply to this post
by Marc Andre Tanner
Marc Andre Tanner wrote:
> - In order for this to be useful it needs to be fast. Nobody wants > to wait 10+ seconds just to select which image to boot. Speed is > therefore the most important factor. [...] > The user can of course still use the hardware buttons to skip the > NAND boot and by pass the bootmenu system. This logic should go the opposite way: by default, don't enter the boot menu but boot straight to the "normal" kernel. If the user does something to get Qi's attention, ignore the default kernel and boot the boot menu. - Werner _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
Carsten Haitzler (The Rasterman)-2
|
In reply to this post
by Marc Andre Tanner
On Thu, 8 Oct 2009 22:50:00 +0200 Marc Andre Tanner <[hidden email]>
said: > Hi all, > > I have been lurking around on various openmoko mailing lists for quite > some time (about 1.5 years) but so far I didn't have the time to actually > contribute anything useful because of study and work related activities. > However during the last few days I actually had some time to waste. > > I therefore looked around for possible projects and found the boot menu > thingy which interested me for quite some time because it involves various > different system parts. > > I have seen in the mailing list archives that some people have actually > already started to work on projects[0] with similar goals but as far as I > know they weren't really finished and/or customized for the Freerunner. > The closest thing to a working solution is probably kexecboot[1]. > > So here are my random thoughts on the subject, comments are appreciated. > > Goals > ===== > > - The user should be able to select which image to boot from > (surprised heh ;) > > - The image could also provide a minimal system rescue environment > that is a sshd server which allows remote access to fix certain > things. > > - In order for this to be useful it needs to be fast. Nobody wants > to wait 10+ seconds just to select which image to boot. Speed is > therefore the most important factor. > > Overview > ======== > > - The whole system could be packaged into an initramfs > > - Ideally I would like to store the boot menu image in NAND flash. > This would ensure that it is always around and different SD > based images could be booted with it. > > The boot sequence would look something like this: > > - Bootloader (Qi) loads minimal kernel > > - kernel extracts initramfs /init is executed > > - application scans for system images on SD card, presents boot menu > > - selected kernel is started via kexec > > > Bootloader (Qi) > =============== > > - I would like to change the default boot sequence to first look > for the special bootmenu image in the kernel NAND flash partition, > if this is not found the boot sequence should proceed with the SD card. > > The user can of course still use the hardware buttons to skip the > NAND boot and by pass the bootmenu system. > > The NAND kernel partition is 8MB large so we need to fit the kernel + > initramfs in there. > > Kernel > ====== > > - optimized for size just the absolutely necessary tings > should be compiled in. The gta02_micro_defconfig will be starting > point for this. Is it still up to date/maintained? > > - compress? Recent kernels can be compressed using LZMA > > Question is if this would actually speed up anything? > Answer depends on where the bottleneck is in data throughput > or computing power. What is the expected data transfer rate > from NAND flash? > > - disable console output completely > > Userland > ======== > > - uClibc > > - stripped down busybox > > - kexec-tools > > They only support zImages however distros ship uImages so > we would either have to strip off the uImage header which is > probably slow or add uImage support to kexec-tools. > > - dropbear sshd > > - bootmenu application (see next section) > > Bootmenu application > ==================== > > - should be something like kexecboot, however It should be finger friendly. > > - functionality should be something like this (taken from kexecboot): > > - read available filesystems from /proc/filesystems > - read available partitions from /proc/partitions > - try to mount each partition, search for zImage in /boot > - present menu > - kexec selected kernel > > - GUI based on elementary with framebuffer support? > > In theory this would be the best solution because we would > use the same technology as in a normal system just with a > different backend. This should ensure that it's actually > finger friendly. Although text entry remains a problem > because the illume keyboard can't be used. But I hope that > text entry won't be necessary anyway (no kernel command line > changes through the GUI, sorry ;) In practice I don't know > how mature the framebuffer backend actually is and it has > quite a few dependcies[2]: > > * eina > * eet > o zlib > o libjpeg > * evas > o freetype i think you missed fontconfig - though it is optional, all the default themes for elementary etc. assume fontconfig support for font naming. > * ecore > o ecore-file > o ecore-evas > o ecore-input > o ecore-job > o ecore-txt > o libiconv (functionality can be provided by uClibc) > o tslib > * edje > o embryo > o lua > * libpng nb. u can drop libpng. if all your image data is inside edje files (or u can put it inot .eet files too) then you won't need this. > I have cross compiled all this and without any special optimisation > (I just disabled everything in ./configure which seemed not critical) > the whole system is about 6-7MB large this is without the kernel. indeed. > I am not familiar with the EFL code base but what I have seen > so far seems like it isn't really optimized for size. So there could > be some potential although it would require some work and upstream > approval. > > Maybe the idea to use elementary is overkill but what are the > alternatives? i'll shime in here. yes. efl has grown over the years, and well - the more functionality you want, the more space it will take. if you are hell-bent on smallest size you possibly would just write your own fb gui that is very simple and ugly (with white/black boxes for example). to reduce complexity i would even remove fonts. what i'd do is: 1. every bootable os provides as well as kernel in /boot/zImage (or wherever), it provides a /boot/bootIcon - this is a simple zlib compressed (see zlib docs on how to simply give it a chunk of data to compress, or decompress). you could avoid compression if u want, but i think this would be worthwhile. lets say the icon data is RGBA (lets use a universal format to account for different devices with different screen depths/formats). aany bootable os must provide this file or it wont be listed. (yes it's an added requirementm but moving work to the bootable os's i takes it out of the qui boot image) 2. within the qui boot fs u include some /boot/wallpaper file - same format as icons. 3. you load wallpaper, convert to screen depth in the simplest/dumbest way (speed isnt important. you are not doing realtime ui rendering). eg for 16bpp this would be: unsigned int *inpix; unsigned short *outpix; *outpix = (((*inpix & 0xff0000) >> 19) << 11) | (((*inpix & 0xff00) >> 10) << 5) | ((*inpix & 0xff) >> 3); i'll leave it up to you to handle other screen formats (32, 24, 18, 15, 12, 8bpp etc.). but one per format. now blend the icons u find (u'll probably just want to blend agaibnst the original rgba wallpaper image and then convert thr result to screen format like above - see google for alpha blending math. its rather simple. it's easy to do, its much more work to do FAST. here speed isnt important as u are just going to render this once and put it up - no realtime ui), one at a time on the screen eg: +-------------+ | | | [ 1 ] [ 2 ] | | | | [ 3 ] [ 4 ] | | | | [ 5 ] [ 6 ] | | | +-------------+ ... etc. as many as the screen fits - the icons themselves can just be an image (eg a penguin) or image + text. u'll probably want to use tslib and get coords when u press to see if up press on one of them - then boot that. you should adjust the layout based on screen size. eg for landscape: +-------------------+ | | | [ 1 ] [ 2 ] [ 3 ] | | | | [ 4 ] [ 5 ] [ 6 ] | | | +-------------------+ this will provide all you need for a grahical boot. it wont be smooth. it wont scroll or animate. it wont let you add much more complexity without a lot of work (eg configuration panels or more than the above hyper-simple boot), but it will function and be very small. of course it's easy for me to say this. i've done all this kind of stuff before. many times. in fact deep down inside efl are semblances of some of this, as just a subset of all that efl does. but it does so much more so it's not small. in return for that footprint you get a small mountain of features. but as i said - easy for me to say the above. i can do it in my sleep - it'sw hat i do, but it's up to you to decide if you are up to doing it at this low level or not. for any reasonable app you'd end up using enough of efl's features to make it worth carrying along its size. it'd be worth the expense, but... for you i don't know if you will ever use all those features. it may simply not be worth it. as long as u use efl your image is not going to be that small. then again you are adding dropbear and thus also enough network config tools to set up usbnet - what about wifi? wireless tools too? how much is the image size when you remove any of the ui bits - all your other parts (libc, busybox, dropbear, network tools to bring up usbnet and/or wifi, wireless tools, dhclient if u have wifi... etc. first see how big that is. how big is it? then relative to that, look at ui. one thing i can suggest. you can drop edje and elementary and do this in just ecore_evas + evas. you could even drop eet here. just 1 image format loader (eg libpng), and you'd be able to i think have a subset of ecore (ecore, ecore_evas, ecore_input, ecore_fb), and just evas + buffer, software_generic and fb engine and just png loader module. no savers modules. now you'd need to create all your own "widgets" - but you could stick to a simple design as above just an array of icons. load the icon files (now u can make them .png files in the boot dirs of the os's) and put them on the screen. you can now easily add callbacks for the mouse down (or up really) on each icon and boot the appropriate os. wallpaper can also be a png file in the qui boot fs. you will be using efl at a lower level. you handle the callbacks directly and place the objects yourself (and handle canvas resizes - yes it can happen even on the fb. eg a resolution change, but in general handling this right just handles the inital fb size right anyway). this will mean you donthave to handle rendering code and different screen formats, image loading or tslib interfacing etc. it should have you a much reduced efl footprint. but keep you from the lowest ugliest bits. hell if you keep all the "os info for the ui" inside the png font handling is moot. u will still need freetype - but u just put name of the os image into the icon itself (nothing 10 seconds in gimp cant do). so to repeat 1. either full efl, elementary etc. - but this will be a big footprint. always 2. subset of efl and keep your ui simple eg as i described above and punt off all the os identification to a png icon as i described above and justddumbly display it and handle events when the user presses it. smaller than full efl but not totally minimal. 3. do it all yourself at the lowest levesl. as small as it will get but by far the most amount of work for you. > Proof of Concept > ================ > > As a proof of concept I started to write a simple shell script (well > in the beginning it was simple in the meantime it evolved in kind of > mini build system, maybe something like OpenWRT could be used but I > wanted a simple solution where I actually understand what's going on) > which downloads and cross compiles everything with an uclibc based > toolchain. > > So far I have cross compiled all the components mentioned in this > post the result is about 6-7MB large. > > I then tried to run the elementary dialog application from the > elementary wiki page[3] in a chrooted system and this works > (although there seems to be a problem with the touchscreen which > doesn't quite work right and sometimes even causes a segfault). do you have ts calibration working? you may actually have problems here in that if the ts is not calibrated and u dont have the right calibration data, it may not be totally useful. but this depends from device to device. as for segv. backtraces please! :) > Another issue is that I currently don't get any console output when > booting from flash with Qi. Although I've added loglevel=8 to Qi's > kernel parameters and recompiled+reflashed. Something with the init > script and/or missing device nodes might be the problem. > > If you want to help then download the scripts and read the README > file of the source tarball. > > http://www.brain-dump.org/tmp/qi-bootmenu-system/qi-bootmenu-system.tar.bz2 > > Once you have a rootfs.tar.gz file generated (after ./build.sh && > ./initramfs.sh && ./package.sh) copy it over to your Freerunner. > Bind mount /proc and /dev to the corresponding directories and try > it out: > > mkdir rootfs > tar -C rootfs -xzf rootfs.tar.gz > mount -t proc /proc rootfs/proc > mount -o bind /dev rootfs/dev > chroot rootfs /usr/bin/ash > export ELM_ENGINE=fb > export ELM_FONT_PATH=/usr/share/fonts > dialog "Hello world, works?" > > My current plan is to fix the initramfs console output (ideas what might > be wrong?). Next step is to launch the elementary dialog app from the init > script. Then shrink/optimize everything until the boot time is acceptable > (or give up if we don't reach that point). And only then start to program > the elementary based kexecboot replacement. This would be my first EFL > application which means I will have to do some research first. > > Comments and/or contributions are welcome and appreciated. > > Happy Hacking, > Marc > > [0] http://thread.gmane.org/gmane.comp.handhelds.openmoko.devel/2011 > [1] http://git.linuxtogo.org/?p=groups/kexecboot/kexecboot.git > [2] > http://www.brain-dump.org/blog/entry/132/On_the_way_towards_a_minimal_elementary_based_boot_system > [3] http://trac.enlightenment.org/e/wiki/Elementary > -- > Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 > > _______________________________________________ > devel mailing list > [hidden email] > https://lists.openmoko.org/mailman/listinfo/devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [hidden email] _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
Martin Jansa
|
On Fri, Oct 09, 2009 at 02:35:14PM +1100, Carsten Haitzler wrote:
> 3. do it all yourself at the lowest levesl. as small as it will get but by far > the most amount of work for you. Would be nice to have also just text-based ui or fb based just as kexecboot have. Recent kexecboot has logo, icons, boot.cfg config file for kernel params, wallpaper would be easy to add I guess. Just POWER button to instruct Qi to boot kernel with menu, then AUX button to change selected item, POWER to use selected (kernel item or ie rescan or some configuration as kexecboot does). BTW: I would prefer to have second instalation of favourite distro on my SD card rather than very limited rescue system in initramfs. just my 2c -- uin:136542059 jid:[hidden email] Jansa Martin sip:[hidden email] JaMa _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
mobi phil
|
Hello,
maybe time for fbui (http://home.comcast.net/~fbui/) ? I think Zack Smith, the author would be happy to help you. mobiphil -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
|
Marc Andre Tanner
|
In reply to this post
by Werner Almesberger
On Thu, Oct 08, 2009 at 09:45:06PM -0300, Werner Almesberger wrote:
> Marc Andre Tanner wrote: > > - In order for this to be useful it needs to be fast. Nobody wants > > to wait 10+ seconds just to select which image to boot. Speed is > > therefore the most important factor. > [...] > > The user can of course still use the hardware buttons to skip the > > NAND boot and by pass the bootmenu system. > > This logic should go the opposite way: by default, don't enter the boot > menu but boot straight to the "normal" kernel. > > If the user does something to get Qi's attention, ignore the default > kernel and boot the boot menu. ACK. It's better that way. This would mean changeing Qi to boot from NAND onces it sees any AUX press. Because otherwise we would have to skip over 2+ SD partition with AUX which doesn't seem to always work reliable. Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
David Samblas Martinez
|
In reply to this post
by Marc Andre Tanner
David Reyes Samblas Martinez
http://www.tuxbrain.com Open ultraportable & embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/10/9 Sander van Grieken <[hidden email]>: > On Friday 09 October 2009 10:28:58 you wrote: >> 2009/10/9 Sander van Grieken <[hidden email]>: >> >> > if speed is a main factor why just keep the boot loader in text mode >> >> > selectionable with aux+power , a kind of dinamic uboot >> >> >> >> sorry I mean why NOT just keep... >> > >> > Also a great idea, but I was commenting on the thoughts of Marc, who >> > more or less alreaqdy decided on that it should be graphical :) >> > >> > grtz, >> > Sander >> >> I forget to add copy to the list, >> Ok a simple gui should not add to much load on the whole process indeed >> > > Take a coffee man, wrong list ;-) sleep, thanks :) > > _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
Tilman Baumann
|
In reply to this post
by Marc Andre Tanner
I love the idea. Especially because I must use uboot since I have no
fallback bootloader for DFU on my GTA01. And uboot can only load kernels from NAND and not from SDHC card. Booting into a minimal bootloader-kernel on NAND and then select different OS on SD has a lot of appeal for me. Because currently I can have multiple installations on SD, but they must share the same kernel image. Marc Andre Tanner wrote: > I have seen in the mailing list archives that some people have actually > already started to work on projects[0] with similar goals but as far as I > know > they weren't really finished and/or customized for the Freerunner. > The closest thing to a working solution is probably kexecboot[1]. -- MFG Tilman Baumann _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
|
Marc Andre Tanner
|
In reply to this post
by Carsten Haitzler (The Rasterman)-2
On Fri, Oct 09, 2009 at 02:35:14PM +1100, Carsten Haitzler wrote:
> On Thu, 8 Oct 2009 22:50:00 +0200 Marc Andre Tanner <[hidden email]> > said: > > > Hi all, > > > > I have been lurking around on various openmoko mailing lists for quite > > some time (about 1.5 years) but so far I didn't have the time to actually > > contribute anything useful because of study and work related activities. > > However during the last few days I actually had some time to waste. > > > > I therefore looked around for possible projects and found the boot menu > > thingy which interested me for quite some time because it involves various > > different system parts. > > > > I have seen in the mailing list archives that some people have actually > > already started to work on projects[0] with similar goals but as far as I > > know they weren't really finished and/or customized for the Freerunner. > > The closest thing to a working solution is probably kexecboot[1]. > > > > So here are my random thoughts on the subject, comments are appreciated. > > > > Goals > > ===== > > > > - The user should be able to select which image to boot from > > (surprised heh ;) > > > > - The image could also provide a minimal system rescue environment > > that is a sshd server which allows remote access to fix certain > > things. > > > > - In order for this to be useful it needs to be fast. Nobody wants > > to wait 10+ seconds just to select which image to boot. Speed is > > therefore the most important factor. > > > > Overview > > ======== > > > > - The whole system could be packaged into an initramfs > > > > - Ideally I would like to store the boot menu image in NAND flash. > > This would ensure that it is always around and different SD > > based images could be booted with it. > > > > The boot sequence would look something like this: > > > > - Bootloader (Qi) loads minimal kernel > > > > - kernel extracts initramfs /init is executed > > > > - application scans for system images on SD card, presents boot menu > > > > - selected kernel is started via kexec > > > > > > Bootloader (Qi) > > =============== > > > > - I would like to change the default boot sequence to first look > > for the special bootmenu image in the kernel NAND flash partition, > > if this is not found the boot sequence should proceed with the SD card. > > > > The user can of course still use the hardware buttons to skip the > > NAND boot and by pass the bootmenu system. > > > > The NAND kernel partition is 8MB large so we need to fit the kernel + > > initramfs in there. > > > > Kernel > > ====== > > > > - optimized for size just the absolutely necessary tings > > should be compiled in. The gta02_micro_defconfig will be starting > > point for this. Is it still up to date/maintained? > > > > - compress? Recent kernels can be compressed using LZMA > > > > Question is if this would actually speed up anything? > > Answer depends on where the bottleneck is in data throughput > > or computing power. What is the expected data transfer rate > > from NAND flash? > > > > - disable console output completely > > > > Userland > > ======== > > > > - uClibc > > > > - stripped down busybox > > > > - kexec-tools > > > > They only support zImages however distros ship uImages so > > we would either have to strip off the uImage header which is > > probably slow or add uImage support to kexec-tools. > > > > - dropbear sshd > > > > - bootmenu application (see next section) > > > > Bootmenu application > > ==================== > > > > - should be something like kexecboot, however It should be finger friendly. > > > > - functionality should be something like this (taken from kexecboot): > > > > - read available filesystems from /proc/filesystems > > - read available partitions from /proc/partitions > > - try to mount each partition, search for zImage in /boot > > - present menu > > - kexec selected kernel > > > > - GUI based on elementary with framebuffer support? > > > > In theory this would be the best solution because we would > > use the same technology as in a normal system just with a > > different backend. This should ensure that it's actually > > finger friendly. Although text entry remains a problem > > because the illume keyboard can't be used. But I hope that > > text entry won't be necessary anyway (no kernel command line > > changes through the GUI, sorry ;) In practice I don't know > > how mature the framebuffer backend actually is and it has > > quite a few dependcies[2]: > > > > * eina > > * eet > > o zlib > > o libjpeg > > * evas > > o freetype > > i think you missed fontconfig - though it is optional, all the default themes > for elementary etc. assume fontconfig support for font naming. Ok now I am confused. Evas actually has support for reading fonts.{dir,alias} files and doesn't require fontconfig for this. Doesn't this work the way I think it does? > > * ecore > > o ecore-file > > o ecore-evas > > o ecore-input > > o ecore-job > > o ecore-txt > > o libiconv (functionality can be provided by uClibc) > > o tslib > > * edje > > o embryo > > o lua > > * libpng > > nb. u can drop libpng. if all your image data is inside edje files (or u can > put it inot .eet files too) then you won't need this. I added libpng because I saw that the default elementary themes uses png files and I thought it needs some way to read them, thus libpng. > > I have cross compiled all this and without any special optimisation > > (I just disabled everything in ./configure which seemed not critical) > > the whole system is about 6-7MB large this is without the kernel. > > indeed. As a said this is without any optimization, no special compilation flags, nothing. I should try to link everything statically which has 2 main advantages: - the linker should be able to remove any code paths which aren't actually used. - at runtime the dynamic linker doesn't have to load all the libraries (less I/O + code relocation) which should speed up the application start. > > I am not familiar with the EFL code base but what I have seen > > so far seems like it isn't really optimized for size. So there could > > be some potential although it would require some work and upstream > > approval. > > > > Maybe the idea to use elementary is overkill but what are the > > alternatives? > > i'll shime in here. yes. efl has grown over the years, and well - the more > functionality you want, the more space it will take. if you are hell-bent on > smallest size you possibly would just write your own fb gui that is very simple > and ugly (with white/black boxes for example). I know that elf provides a lot of features and is rather small for what it does (don't get me started on gtk or qt). But what suprised me for example was that although I had compiled elementary with just the framebuffer backend it nevertheless tried to use the X backend unless it was told to not do so (with ELM_ENGINE=fb). So there apparently is code there which strictly speaking doesn't has to be there. Another thing is the lua/embryo thing. If I am not mistaken they basically do the same thing so it should be possible to only use one of the two. Lua was added recently and should become the default, right? So embryo will go away in the long run, correct? But I guess it will be needed for backwards compatibility anyway so in my opinion it should be possible to disable lua at compile time. > to reduce complexity i would even remove fonts. what i'd do is: > > 1. every bootable os provides as well as kernel in /boot/zImage (or wherever), > it provides a /boot/bootIcon - this is a simple zlib compressed (see zlib docs > on how to simply give it a chunk of data to compress, or decompress). you could > avoid compression if u want, but i think this would be worthwhile. lets say the > icon data is RGBA (lets use a universal format to account for different > devices with different screen depths/formats). aany bootable os must provide > this file or it wont be listed. (yes it's an added requirementm but moving work > to the bootable os's i takes it out of the qui boot image) > 2. within the qui boot fs u include some /boot/wallpaper file - same format as > icons. > 3. you load wallpaper, convert to screen depth in the simplest/dumbest way > (speed isnt important. you are not doing realtime ui rendering). eg for 16bpp > this would be: > > unsigned int *inpix; > unsigned short *outpix; > > *outpix = (((*inpix & 0xff0000) >> 19) << 11) | (((*inpix & 0xff00) >> 10) << > 5) | ((*inpix & 0xff) >> 3); > > i'll leave it up to you to handle other screen formats (32, 24, 18, 15, 12, > 8bpp etc.). but one per format. > > now blend the icons u find (u'll probably just want to blend agaibnst the > original rgba wallpaper image and then convert thr result to screen format like > above - see google for alpha blending math. its rather simple. it's easy to do, > its much more work to do FAST. here speed isnt important as u are just going to > render this once and put it up - no realtime ui), one at a time on the screen > eg: > > +-------------+ > | | > | [ 1 ] [ 2 ] | > | | > | [ 3 ] [ 4 ] | > | | > | [ 5 ] [ 6 ] | > | | > +-------------+ > ... etc. > > as many as the screen fits - the icons themselves can just be an image (eg a > penguin) or image + text. u'll probably want to use tslib and get coords when u > press to see if up press on one of them - then boot that. you should adjust the > layout based on screen size. eg for landscape: > > +-------------------+ > | | > | [ 1 ] [ 2 ] [ 3 ] | > | | > | [ 4 ] [ 5 ] [ 6 ] | > | | > +-------------------+ > > this will provide all you need for a grahical boot. it wont be smooth. it wont > scroll or animate. it wont let you add much more complexity without a lot of > work (eg configuration panels or more than the above hyper-simple boot), but it > will function and be very small. Thanks for your insight. I think it's a little to low level for me right now, afterall I have a limited amount of time I can spend on this. The key is probably to get the right balance between the amount of work and usability / performance. For now I will leave some abstraction layers in and see how small/fast this can be made. > of course it's easy for me to say this. i've done all this kind of stuff > before. many times. in fact deep down inside efl are semblances of some of > this, as just a subset of all that efl does. but it does so much more so it's > not small. in return for that footprint you get a small mountain of features. > but as i said - easy for me to say the above. i can do it in my sleep - > it'sw hat i do, but it's up to you to decide if you are up to doing it at this > low level or not. for any reasonable app you'd end up using enough of efl's > features to make it worth carrying along its size. it'd be worth the expense, > but... for you i don't know if you will ever use all those features. it may > simply not be worth it. as long as u use efl your image is not going to be that > small. then again you are adding dropbear and thus also enough network config > tools to set up usbnet This should be covered by busybox i hope. > - what about wifi? wireless tools too? how much is the Not going to happen (at least not by me). The network support is just to provide a kind of minimal rescue system to ssh in over usb, mount the sd card and then chroot into the regular system to fix something. It's not intended to get some kernel + root filesystem from a NFS server over wifi. Anyway if the usb network support should be the few KBs which make it to large/slow then I will probably drop them. > image size when you remove any of the ui bits - all your other parts (libc, > busybox, dropbear, network tools to bring up usbnet and/or wifi, wireless > tools, dhclient if u have wifi... etc. first see how big that is. how big is > it? then relative to that, look at ui. I agree that this is the right approach. Antoher interesting thing is how much an aditional MB actually costs in terms of speed (copy from NAND to RAM). Below is a listing of my current initramfs files sorted by size. Now that I compare them to my SHR system I see that they are a lot larger. For example libevas-* is only 687K on my SHR. I will have to investigate if this is just because of the missing optimization flags in my $CFLAGS or what causes this. 928K ./usr/lib/libevas-ver-pre-svn-04.so.0.9.9 648K ./usr/lib/libedje-ver-pre-svn-04.so.0.9.92 584K ./usr/share/fonts/DejaVuSans.ttf 512K ./usr/lib/libuClibc-0.9.30.1.so 448K ./usr/lib/libfreetype.so.6.3.20 384K ./usr/lib/libelementary-ver-pre-svn-04.so.0.5.1 356K ./usr/bin/busybox 328K ./usr/share/elementary/themes/default.edj 272K ./usr/lib/libjpeg.so.7.0.0 224K ./usr/lib/libpng12.so.0.40.0 212K ./usr/sbin/dropbearmulti 168K ./usr/lib/libecore-ver-pre-svn-04.so.0.9.9 108K ./usr/lib/libeet.so.1.2.2 100K ./usr/lib/libeina-ver-pre-svn-04.so.0.0.2 88K ./usr/sbin/kexec 84K ./usr/lib/libz.so.1.2.3 84K ./usr/lib/libecore_evas-ver-pre-svn-04.so.0.9.9 80K ./usr/lib/libm-0.9.30.1.so 68K ./usr/lib/libpthread-0.9.30.1.so 44K ./usr/lib/libembryo-ver-pre-svn-04.so.0.9.9 44K ./usr/lib/libecore_con-ver-pre-svn-04.so.0.9.9 40K ./usr/lib/libecore_fb-ver-pre-svn-04.so.0.9.9 28K ./usr/lib/evas/modules/engines/fb/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so 24K ./usr/lib/libecore_file-ver-pre-svn-04.so.0.9.9 24K ./usr/lib/ld-uClibc-0.9.30.1.so 24K ./usr/lib/evas/modules/engines/software_generic/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so 20K ./usr/lib/evas/modules/loaders/jpeg/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so 16K ./usr/lib/libecore_input-ver-pre-svn-04.so.0.9.9 16K ./usr/lib/libcrypt-0.9.30.1.so 16K ./usr/lib/evas/modules/engines/buffer/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so 12K ./usr/lib/libdl-0.9.30.1.so 8.0K ./usr/lib/ts/variance.so 8.0K ./usr/lib/ts/linear.so 8.0K ./usr/lib/ts/input.so 8.0K ./usr/lib/ts/dejitter.so 8.0K ./usr/lib/libutil-0.9.30.1.so 8.0K ./usr/lib/libts-1.0.so.0.0.0 8.0K ./usr/lib/librt-0.9.30.1.so 8.0K ./usr/lib/libresolv-0.9.30.1.so 8.0K ./usr/lib/libnsl-0.9.30.1.so 8.0K ./usr/lib/libecore_job-ver-pre-svn-04.so.0.9.9 8.0K ./usr/lib/evas/modules/savers/png/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so 8.0K ./usr/lib/evas/modules/savers/jpeg/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so 8.0K ./usr/lib/evas/modules/savers/eet/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so 8.0K ./usr/lib/evas/modules/loaders/png/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so 8.0K ./usr/lib/evas/modules/loaders/eet/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so 8.0K ./usr/lib/eina/mp/eina_chained_mempool.so 8.0K ./usr/bin/dialog 4.0K ./usr/sbin/init 4.0K ./usr/lib/ts/tatung.so 4.0K ./usr/lib/ts/pthres.so 4.0K ./usr/lib/libecore_txt-ver-pre-svn-04.so.0.9.9 4.0K ./usr/lib/libc.so 4.0K ./usr/lib/eina/mp/eina_pass_through.so 4.0K ./usr/etc/ts.conf 4.0K ./usr/etc/passwd 4.0K ./usr/etc/fb.modes > one thing i can suggest. you can drop edje and elementary and do this in just > ecore_evas + evas. you could even drop eet here. just 1 image format loader (eg > libpng), and you'd be able to i think have a subset of ecore (ecore, > ecore_evas, ecore_input, ecore_fb), and just evas + buffer, software_generic > and fb engine and just png loader module. no savers modules. > > now you'd need to create all your own "widgets" - but you could stick to a > simple design as above just an array of icons. load the icon files (now u can > make them .png files in the boot dirs of the os's) and put them on the screen. > you can now easily add callbacks for the mouse down (or up really) on each icon > and boot the appropriate os. wallpaper can also be a png file in the qui boot > fs. you will be using efl at a lower level. you handle the callbacks directly > and place the objects yourself (and handle canvas resizes - yes it can happen > even on the fb. eg a resolution change, but in general handling this right > just handles the inital fb size right anyway). this will mean you donthave to > handle rendering code and different screen formats, image loading or tslib > interfacing etc. it should have you a much reduced efl footprint. but keep you > from the lowest ugliest bits. hell if you keep all the "os info for the ui" > inside the png font handling is moot. u will still need freetype - but u just > put name of the os image into the icon itself (nothing 10 seconds in gimp cant > do). > > so to repeat > > 1. either full efl, elementary etc. - but this will be a big footprint. always > 2. subset of efl and keep your ui simple eg as i described above and punt off > all the os identification to a png icon as i described above and justddumbly > display it and handle events when the user presses it. smaller than full efl > but not totally minimal. > 3. do it all yourself at the lowest levesl. as small as it will get but by far > the most amount of work for you. Thanks for this nice overview. I would like to try it in that order and see how useable it is speed wise and if it's too slow then move to the next variant and remove one layer of abstraction. For now I am working with option 1. As I said in my first mail it would be nice to use the same technology just with a different backend and therefore reuse all the work you and others have put into it. Option 3 (although probably not as low level as you described it) is what kexecboot does. It would therefore be an option to add touchscreen support to kexecboot. I would probably not be as pretty as an elementary based solution if there are people who actually care about the optical aspect of the thing. > > Proof of Concept > > ================ > > > > As a proof of concept I started to write a simple shell script (well > > in the beginning it was simple in the meantime it evolved in kind of > > mini build system, maybe something like OpenWRT could be used but I > > wanted a simple solution where I actually understand what's going on) > > which downloads and cross compiles everything with an uclibc based > > toolchain. > > > > So far I have cross compiled all the components mentioned in this > > post the result is about 6-7MB large. > > > > I then tried to run the elementary dialog application from the > > elementary wiki page[3] in a chrooted system and this works > > (although there seems to be a problem with the touchscreen which > > doesn't quite work right and sometimes even causes a segfault). > > do you have ts calibration working? Don't know yet, I have just copied over the ts.conf from SHR so that it at least uses the same/right modules. Touchscreen calibration is the next thing I need to look into. Because I tested this in a chroot from within a SHR system I thought the touchscreen would already be in a redy-to-use state (i.e calibrated) is this a wrong assumption? Anyone want to share a known to work receipt for touchscreen calibration on the Freerunner? > you may actually have problems here in that > if the ts is not calibrated and u dont have the right calibration data, it may > not be totally useful. but this depends from device to device. as for segv. > backtraces please! :) Will have to reproduce it later on. Thanks for your comments. Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
|
Marc Andre Tanner
|
In reply to this post
by Martin Jansa
On Fri, Oct 09, 2009 at 06:32:20AM +0200, Martin Jansa wrote:
> On Fri, Oct 09, 2009 at 02:35:14PM +1100, Carsten Haitzler wrote: > > 3. do it all yourself at the lowest levesl. as small as it will get but by far > > the most amount of work for you. > > Would be nice to have also just text-based ui or fb based just as > kexecboot have. Recent kexecboot has logo, icons, boot.cfg config file for kernel > params, wallpaper would be easy to add I guess. I agree that kexecboot with some patches to make it touchscreen aware would be an option but for now (and until it's proved to be too slow) I prefer an elementary based solution. > Just POWER button to instruct Qi to boot kernel with menu, then AUX button to change > selected item, POWER to use selected (kernel item or ie rescan or some > configuration as kexecboot does). Well this kind of works alredy with Qi alone: AUX skips a partion. Unfortunately this is a bit cumbersome. But in my opinion if we spend the time to do an initramfs we could as well make it touchscreen aware and visually appealing. Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
|
Marc Andre Tanner
|
In reply to this post
by mobi phil
On Fri, Oct 09, 2009 at 09:43:39AM +0200, mobi phil wrote:
> Hello, > > maybe time for fbui (http://home.comcast.net/~fbui/) ? I think Zack > Smith, the author would be happy to help you. To quote from the web page: "It currently only works with kernel 2.6.9, although I've got it partially working on 2.6.31". This is alone is a deal breaker. The last thing that we need is another out of vanilla kernel.org component we are struggling enough with getting all the Openmoko specific drivers/patches upstream. Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
|
Marc Andre Tanner
|
In reply to this post
by David Samblas Martinez
On Fri, Oct 09, 2009 at 10:53:40AM +0200, David Reyes Samblas Martinez wrote:
> 2009/10/9 Sander van Grieken <[hidden email]>: > > On Friday 09 October 2009 10:28:58 you wrote: > >> 2009/10/9 Sander van Grieken <[hidden email]>: > >> >> > if speed is a main factor why just keep the boot loader in text mode > >> >> > selectionable with aux+power , a kind of dinamic uboot > >> >> > >> >> sorry I mean why NOT just keep... I think this is no real improvement over the situation as it is now. Qi already supports boot selection via AUX which skips a partition although it is a bit cumbersome. At the moment I prefer a 'full-featured' solution, if this proves to be unuseable speed wise we can still fallback to this basic variants. Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
Petr Vanek
|
In reply to this post
by Marc Andre Tanner
>On Fri, Oct 09, 2009 at 09:43:39AM +0200, mobi phil wrote:
>> Hello, >> >> maybe time for fbui (http://home.comcast.net/~fbui/) ? I think Zack >> Smith, the author would be happy to help you. > >To quote from the web page: "It currently only works with kernel 2.6.9, >although I've got it partially working on 2.6.31". > >This is alone is a deal breaker. The last thing that we need is another >out of vanilla kernel.org component we are struggling enough with >getting all the Openmoko specific drivers/patches upstream. as this kernel would really not get updated often and not load any drivers, would it be an issue here? anyhow, just my 2c on another note: when i was playing with the proof of concept on the boot menu one thing seemed to be an advantage to implement - possibility to call fsck on any ext filesystem (i actually added it into the menu)... Petr _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
|
Petr Vanek
|
In reply to this post
by Marc Andre Tanner
>I think this is no real improvement over the situation as it is now.
>Qi already supports boot selection via AUX which skips a partition >although it is a bit cumbersome. agree >At the moment I prefer a 'full-featured' solution, if this proves to >be unuseable speed wise we can still fallback to this basic variants. makes sense. have you tried the proof of concept with X server? my wish always was to use fb instead of X... i am hoping fb based image will be much smaller and faster then X... Petr _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
|
Werner Almesberger
|
In reply to this post
by Marc Andre Tanner
Marc Andre Tanner wrote:
> ACK. It's better that way. This would mean changeing Qi to boot from NAND > onces it sees any AUX press. Because otherwise we would have to skip over > 2+ SD partition with AUX which doesn't seem to always work reliable. I'd rather try to go away from NAND. More modern CPUs can boot from SD directly and thus don't need that quirky NAND at all. There's the question of whether manually interacting with Qi should select a different partition or whether it should select a different kernel name (or some other marker), which is then used with the usual partition search. (At the end of the search, one can still try NAND.) I don't think it's a good idea to try to select among more than two partitions in Qi. That's just feature creep. Better to have a default vs. menu choice that works reliably. - Werner _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
|
Carsten Haitzler (The Rasterman)-2
|
In reply to this post
by Marc Andre Tanner
On Fri, 9 Oct 2009 13:00:12 +0200 Marc Andre Tanner <[hidden email]>
said: > On Fri, Oct 09, 2009 at 02:35:14PM +1100, Carsten Haitzler wrote: > > On Thu, 8 Oct 2009 22:50:00 +0200 Marc Andre Tanner > > <[hidden email]> said: > > > > > Hi all, > > > > > > I have been lurking around on various openmoko mailing lists for quite > > > some time (about 1.5 years) but so far I didn't have the time to actually > > > contribute anything useful because of study and work related activities. > > > However during the last few days I actually had some time to waste. > > > > > > I therefore looked around for possible projects and found the boot menu > > > thingy which interested me for quite some time because it involves various > > > different system parts. > > > > > > I have seen in the mailing list archives that some people have actually > > > already started to work on projects[0] with similar goals but as far as I > > > know they weren't really finished and/or customized for the Freerunner. > > > The closest thing to a working solution is probably kexecboot[1]. > > > > > > So here are my random thoughts on the subject, comments are appreciated. > > > > > > Goals > > > ===== > > > > > > - The user should be able to select which image to boot from > > > (surprised heh ;) > > > > > > - The image could also provide a minimal system rescue environment > > > that is a sshd server which allows remote access to fix certain > > > things. > > > > > > - In order for this to be useful it needs to be fast. Nobody wants > > > to wait 10+ seconds just to select which image to boot. Speed is > > > therefore the most important factor. > > > > > > Overview > > > ======== > > > > > > - The whole system could be packaged into an initramfs > > > > > > - Ideally I would like to store the boot menu image in NAND flash. > > > This would ensure that it is always around and different SD > > > based images could be booted with it. > > > > > > The boot sequence would look something like this: > > > > > > - Bootloader (Qi) loads minimal kernel > > > > > > - kernel extracts initramfs /init is executed > > > > > > - application scans for system images on SD card, presents boot menu > > > > > > - selected kernel is started via kexec > > > > > > > > > Bootloader (Qi) > > > =============== > > > > > > - I would like to change the default boot sequence to first look > > > for the special bootmenu image in the kernel NAND flash partition, > > > if this is not found the boot sequence should proceed with the SD card. > > > > > > The user can of course still use the hardware buttons to skip the > > > NAND boot and by pass the bootmenu system. > > > > > > The NAND kernel partition is 8MB large so we need to fit the kernel + > > > initramfs in there. > > > > > > Kernel > > > ====== > > > > > > - optimized for size just the absolutely necessary tings > > > should be compiled in. The gta02_micro_defconfig will be starting > > > point for this. Is it still up to date/maintained? > > > > > > - compress? Recent kernels can be compressed using LZMA > > > > > > Question is if this would actually speed up anything? > > > Answer depends on where the bottleneck is in data throughput > > > or computing power. What is the expected data transfer rate > > > from NAND flash? > > > > > > - disable console output completely > > > > > > Userland > > > ======== > > > > > > - uClibc > > > > > > - stripped down busybox > > > > > > - kexec-tools > > > > > > They only support zImages however distros ship uImages so > > > we would either have to strip off the uImage header which is > > > probably slow or add uImage support to kexec-tools. > > > > > > - dropbear sshd > > > > > > - bootmenu application (see next section) > > > > > > Bootmenu application > > > ==================== > > > > > > - should be something like kexecboot, however It should be finger > > > friendly. > > > > > > - functionality should be something like this (taken from kexecboot): > > > > > > - read available filesystems from /proc/filesystems > > > - read available partitions from /proc/partitions > > > - try to mount each partition, search for zImage in /boot > > > - present menu > > > - kexec selected kernel > > > > > > - GUI based on elementary with framebuffer support? > > > > > > In theory this would be the best solution because we would > > > use the same technology as in a normal system just with a > > > different backend. This should ensure that it's actually > > > finger friendly. Although text entry remains a problem > > > because the illume keyboard can't be used. But I hope that > > > text entry won't be necessary anyway (no kernel command line > > > changes through the GUI, sorry ;) In practice I don't know > > > how mature the framebuffer backend actually is and it has > > > quite a few dependcies[2]: > > > > > > * eina > > > * eet > > > o zlib > > > o libjpeg > > > * evas > > > o freetype > > > > i think you missed fontconfig - though it is optional, all the default > > themes for elementary etc. assume fontconfig support for font naming. > > Ok now I am confused. Evas actually has support for reading fonts.{dir,alias} > files and doesn't require fontconfig for this. Doesn't this work the way I > think it does? oh wait. sorry. fonts.dir and fonts.alias are built-in. they are old x-stile font naming schemes. its a simple parser. fontconfig provides things like Sans etc. normally. i've actually totally forgotten about that code. it's ancient. interesting that it still works! :) > > > * ecore > > > o ecore-file > > > o ecore-evas > > > o ecore-input > > > o ecore-job > > > o ecore-txt > > > o libiconv (functionality can be provided by uClibc) > > > o tslib > > > * edje > > > o embryo > > > o lua > > > * libpng > > > > nb. u can drop libpng. if all your image data is inside edje files (or u can > > put it inot .eet files too) then you won't need this. > > I added libpng because I saw that the default elementary themes uses png files > and I thought it needs some way to read them, thus libpng. the theme does. but its compiled into a .edj file. once there it is no longer png :) no need for png.. unless u - un your app, specify png files for things :) > > > I have cross compiled all this and without any special optimisation > > > (I just disabled everything in ./configure which seemed not critical) > > > the whole system is about 6-7MB large this is without the kernel. > > > > indeed. > > As a said this is without any optimization, no special compilation flags, > nothing. I should try to link everything statically which has 2 main > advantages: you will save very little with things like -Os. maybe 5-10%. on a good day. that ballpark. > - the linker should be able to remove any code paths which aren't actually > used. not from share libraries. only if you statically compile with executables. > - at runtime the dynamic linker doesn't have to load all the libraries > (less I/O + code relocation) which should speed up the application start. > > > > I am not familiar with the EFL code base but what I have seen > > > so far seems like it isn't really optimized for size. So there could > > > be some potential although it would require some work and upstream > > > approval. > > > > > > Maybe the idea to use elementary is overkill but what are the > > > alternatives? > > > > i'll shime in here. yes. efl has grown over the years, and well - the more > > functionality you want, the more space it will take. if you are hell-bent on > > smallest size you possibly would just write your own fb gui that is very > > simple and ugly (with white/black boxes for example). > > I know that elf provides a lot of features and is rather small for what it > does (don't get me started on gtk or qt). But what suprised me for example > was that although I had compiled elementary with just the framebuffer backend > it nevertheless tried to use the X backend unless it was told to not do so > (with ELM_ENGINE=fb). So there apparently is code there which strictly > speaking doesn't has to be there. x11 engine is the default. thats just how the code is. :) if its not coimpiled in you just get stubs trying to use the engine and returning 0 saying they cant (ie nothing compiled in) you wont save more than a dozen or 2 bytes by trying to remove these stubs entirely. its not worth it. > Another thing is the lua/embryo thing. If I am not mistaken they basically do > the same thing so it should be possible to only use one of the two. Lua was > added recently and should become the default, right? So embryo will go away in > the long run, correct? But I guess it will be needed for backwards > compatibility anyway so in my opinion it should be possible to disable lua at > compile time. there .. no. embryo is there because it is a default feature of edje. lua is as of recently also a default feature. it is required because all edje files are equally capable. i do not want an edje that "might not work with some edje files". it's not going to happen because as policy i want all edje files and themes to work the same everywhere. not fail or work stangely because someone happend to build without the support somewhere. thus you will need both. note. embryo is TINY. its runtime library is on the order of about 40kb. thats the footprint. the bits in edje that hook to it might be another 10kb of code at worst. lua is much bigger - but we are now using it because it saves us work and adds more power. it's not fully up and ready yet, but it will be. so you're getting both embryo and lua. one way or another. (not embryo script is compiled to bytecode and put into the .edj files. its is VERY fast to execute. about 2x faster than java. it wil be many times faster than lua to execute the same logic, so as long as you want just simple logic - use embryo script. if u want to get more complex and imaginative.. then u want lua - so there is a very good reason to keep both. efficiency) > > to reduce complexity i would even remove fonts. what i'd do is: > > > > 1. every bootable os provides as well as kernel in /boot/zImage (or > > wherever), it provides a /boot/bootIcon - this is a simple zlib compressed > > (see zlib docs on how to simply give it a chunk of data to compress, or > > decompress). you could avoid compression if u want, but i think this would > > be worthwhile. lets say the icon data is RGBA (lets use a universal format > > to account for different devices with different screen depths/formats). > > aany bootable os must provide this file or it wont be listed. (yes it's an > > added requirementm but moving work to the bootable os's i takes it out of > > the qui boot image) > > 2. within the qui boot fs u include some /boot/wallpaper file - same format > > as icons. > > 3. you load wallpaper, convert to screen depth in the simplest/dumbest way > > (speed isnt important. you are not doing realtime ui rendering). eg for > > 16bpp this would be: > > > > unsigned int *inpix; > > unsigned short *outpix; > > > > *outpix = (((*inpix & 0xff0000) >> 19) << 11) | (((*inpix & 0xff00) >> 10) > > << > > 5) | ((*inpix & 0xff) >> 3); > > > > i'll leave it up to you to handle other screen formats (32, 24, 18, 15, 12, > > 8bpp etc.). but one per format. > > > > now blend the icons u find (u'll probably just want to blend agaibnst the > > original rgba wallpaper image and then convert thr result to screen format > > like above - see google for alpha blending math. its rather simple. it's > > easy to do, its much more work to do FAST. here speed isnt important as u > > are just going to render this once and put it up - no realtime ui), one at > > a time on the screen eg: > > > > +-------------+ > > | | > > | [ 1 ] [ 2 ] | > > | | > > | [ 3 ] [ 4 ] | > > | | > > | [ 5 ] [ 6 ] | > > | | > > +-------------+ > > ... etc. > > > > as many as the screen fits - the icons themselves can just be an image (eg a > > penguin) or image + text. u'll probably want to use tslib and get coords > > when u press to see if up press on one of them - then boot that. you should > > adjust the layout based on screen size. eg for landscape: > > > > +-------------------+ > > | | > > | [ 1 ] [ 2 ] [ 3 ] | > > | | > > | [ 4 ] [ 5 ] [ 6 ] | > > | | > > +-------------------+ > > > > this will provide all you need for a grahical boot. it wont be smooth. it > > wont scroll or animate. it wont let you add much more complexity without a > > lot of work (eg configuration panels or more than the above hyper-simple > > boot), but it will function and be very small. > > Thanks for your insight. I think it's a little to low level for me right now, > afterall I have a limited amount of time I can spend on this. The key is > probably to get the right balance between the amount of work and usability / > performance. For now I will leave some abstraction layers in and see how > small/fast this can be made. > > > of course it's easy for me to say this. i've done all this kind of stuff > > before. many times. in fact deep down inside efl are semblances of some of > > this, as just a subset of all that efl does. but it does so much more so > > it's not small. in return for that footprint you get a small mountain of > > features. but as i said - easy for me to say the above. i can do it in my > > sleep - it'sw hat i do, but it's up to you to decide if you are up to doing > > it at this low level or not. for any reasonable app you'd end up using > > enough of efl's features to make it worth carrying along its size. it'd be > > worth the expense, but... for you i don't know if you will ever use all > > those features. it may simply not be worth it. as long as u use efl your > > image is not going to be that small. then again you are adding dropbear and > > thus also enough network config tools to set up usbnet > > This should be covered by busybox i hope. hopefully, but every busybox feature added is more space. > > - what about wifi? wireless tools too? how much is the > > Not going to happen (at least not by me). The network support is just to > provide a kind of minimal rescue system to ssh in over usb, mount the sd card > and then chroot into the regular system to fix something. It's not intended > to get some kernel + root filesystem from a NFS server over wifi. Anyway if > the usb network support should be the few KBs which make it to large/slow > then I will probably drop them. ok. > > image size when you remove any of the ui bits - all your other parts (libc, > > busybox, dropbear, network tools to bring up usbnet and/or wifi, wireless > > tools, dhclient if u have wifi... etc. first see how big that is. how big is > > it? then relative to that, look at ui. > > I agree that this is the right approach. Antoher interesting thing is how much > an aditional MB actually costs in terms of speed (copy from NAND to RAM). oh true. though it might work best as a real jffs or cramfs fs instead of initrd - it's flash. you have no seek overhead so a linear read isnt going to be much better than a sparse fetch of whats needed from jffs2 or cramfs. in fact chancges are u'll be better off as u fecth "on demand" as opposed to read everything even though some of it isnt needed. my suggestion might be cramfs as its going to compress best. :) > Below is a listing of my current initramfs files sorted by size. Now that I > compare them to my SHR system I see that they are a lot larger. For example > libevas-* is only 687K on my SHR. I will have to investigate if this is just > because of the missing optimization flags in my $CFLAGS or what causes this. ok. for option 1, u can nuke libpng. thats 224k gone. libecore_con should be able to go. i can't think of a reason you need it. another 44k gone. the evas jpeg image loader can go. another 20k. all the saver modules for evas can go and the png loader. thats a total of 32k gone. now elementary's default them can be very much trimmed. it has images - a fair few in it. if you used fewer images and smaller ones that were much simpler and re-used a lot, it'd make it smaller. you could get that default theme down to maybe 50-100k without much trouble. also you use DejaVuSans.ttf - its HUGE. it has lots of chars for all sorts of international text (outside of latin/western european). the standard and much smaller Vera.ttf is only 72k. (DejaVu was a modified Vera with all these extra chars added). so you could save 512k by using plain old vera instead (this i think has western european accented chars like ö and é œ ß etc. so u could even handle that, but for a bootloader i suspect normal lasting/ascii is just fine. right?). so.. lets see. for your #1 i can find 224+44+20+32+512k of savings without changing any functionality or doing any real work except deleting files. that's 832k to squeeze out there. you can add another probably 250k of savings if u spend time in making a very lean theme. so we're about 1.1mb now to lose (of uncomrpessed files - and of course this is rounding up all files to 4k blocks of savings may be a little less). now if u did option #2 and did a lower level ui with no text (text in the icons) just with evas + ecore-evas, you could save an extra (on top of the total savings above) if you put png loader back but remove eet (this means u dont need libjpeg anymore), so... +224 -272 -108 -648 -72 -384 -78 -44 -8 +8 (trust me on this) ... another 1382k of savings on top of the reduction in #1. in #2 efl itself will have a footrpint of 928+448+224+168+100+84+28+24+24+16+16 +32+8+8+8+8+4+4+4+4... 2100kb. so thats efl's footprint (approximately) in addition to a minimal core os. thats whgat it costs you in space for efl to save you work for #2 - of course #1 will cost an extra 1382kb on top of this so that is about the best i can do for you. note these numebers are uncomrpessed. comrprssed expect the numebrs to about halve. ie efl costs u about 1mb of "storage" as after compression thats what u'll get. elementary, edje and friends will cost u another about 700k on top. based on your numbers below. :) that's not a hell of a lot. > 928K ./usr/lib/libevas-ver-pre-svn-04.so.0.9.9 > 648K ./usr/lib/libedje-ver-pre-svn-04.so.0.9.92 > 584K ./usr/share/fonts/DejaVuSans.ttf > 512K ./usr/lib/libuClibc-0.9.30.1.so > 448K ./usr/lib/libfreetype.so.6.3.20 > 384K ./usr/lib/libelementary-ver-pre-svn-04.so.0.5.1 > 356K ./usr/bin/busybox > 328K ./usr/share/elementary/themes/default.edj > 272K ./usr/lib/libjpeg.so.7.0.0 > 224K ./usr/lib/libpng12.so.0.40.0 > 212K ./usr/sbin/dropbearmulti > 168K ./usr/lib/libecore-ver-pre-svn-04.so.0.9.9 > 108K ./usr/lib/libeet.so.1.2.2 > 100K ./usr/lib/libeina-ver-pre-svn-04.so.0.0.2 > 88K ./usr/sbin/kexec > 84K ./usr/lib/libz.so.1.2.3 > 84K ./usr/lib/libecore_evas-ver-pre-svn-04.so.0.9.9 > 80K ./usr/lib/libm-0.9.30.1.so > 68K ./usr/lib/libpthread-0.9.30.1.so > 44K ./usr/lib/libembryo-ver-pre-svn-04.so.0.9.9 > 44K ./usr/lib/libecore_con-ver-pre-svn-04.so.0.9.9 > 40K ./usr/lib/libecore_fb-ver-pre-svn-04.so.0.9.9 > 28K ./usr/lib/evas/modules/engines/fb/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so > 24K ./usr/lib/libecore_file-ver-pre-svn-04.so.0.9.9 > 24K ./usr/lib/ld-uClibc-0.9.30.1.so > 24K ./usr/lib/evas/modules/engines/software_generic/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so > 20K ./usr/lib/evas/modules/loaders/jpeg/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so > 16K ./usr/lib/libecore_input-ver-pre-svn-04.so.0.9.9 > 16K ./usr/lib/libcrypt-0.9.30.1.so > 16K ./usr/lib/evas/modules/engines/buffer/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so > 12K ./usr/lib/libdl-0.9.30.1.so > 8.0K ./usr/lib/ts/variance.so > 8.0K ./usr/lib/ts/linear.so > 8.0K ./usr/lib/ts/input.so > 8.0K ./usr/lib/ts/dejitter.so > 8.0K ./usr/lib/libutil-0.9.30.1.so > 8.0K ./usr/lib/libts-1.0.so.0.0.0 > 8.0K ./usr/lib/librt-0.9.30.1.so > 8.0K ./usr/lib/libresolv-0.9.30.1.so > 8.0K ./usr/lib/libnsl-0.9.30.1.so > 8.0K ./usr/lib/libecore_job-ver-pre-svn-04.so.0.9.9 > 8.0K ./usr/lib/evas/modules/savers/png/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so > 8.0K ./usr/lib/evas/modules/savers/jpeg/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so > 8.0K ./usr/lib/evas/modules/savers/eet/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so > 8.0K ./usr/lib/evas/modules/loaders/png/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so > 8.0K ./usr/lib/evas/modules/loaders/eet/linux-gnueabi-armv4tl-ver-pre-svn-04/module.so > 8.0K ./usr/lib/eina/mp/eina_chained_mempool.so > 8.0K ./usr/bin/dialog > 4.0K ./usr/sbin/init > 4.0K ./usr/lib/ts/tatung.so > 4.0K ./usr/lib/ts/pthres.so > 4.0K ./usr/lib/libecore_txt-ver-pre-svn-04.so.0.9.9 > 4.0K ./usr/lib/libc.so > 4.0K ./usr/lib/eina/mp/eina_pass_through.so > 4.0K ./usr/etc/ts.conf > 4.0K ./usr/etc/passwd > 4.0K ./usr/etc/fb.modes > > > one thing i can suggest. you can drop edje and elementary and do this in > > just ecore_evas + evas. you could even drop eet here. just 1 image format > > loader (eg libpng), and you'd be able to i think have a subset of ecore > > (ecore, ecore_evas, ecore_input, ecore_fb), and just evas + buffer, > > software_generic and fb engine and just png loader module. no savers > > modules. > > > > now you'd need to create all your own "widgets" - but you could stick to a > > simple design as above just an array of icons. load the icon files (now u > > can make them .png files in the boot dirs of the os's) and put them on the > > screen. you can now easily add callbacks for the mouse down (or up really) > > on each icon and boot the appropriate os. wallpaper can also be a png file > > in the qui boot fs. you will be using efl at a lower level. you handle the > > callbacks directly and place the objects yourself (and handle canvas > > resizes - yes it can happen even on the fb. eg a resolution change, but in > > general handling this right just handles the inital fb size right anyway). > > this will mean you donthave to handle rendering code and different screen > > formats, image loading or tslib interfacing etc. it should have you a much > > reduced efl footprint. but keep you from the lowest ugliest bits. hell if > > you keep all the "os info for the ui" inside the png font handling is moot. > > u will still need freetype - but u just put name of the os image into the > > icon itself (nothing 10 seconds in gimp cant do). > > > > so to repeat > > > > 1. either full efl, elementary etc. - but this will be a big footprint. > > always > > 2. subset of efl and keep your ui simple eg as i described above and punt > > off all the os identification to a png icon as i described above and > > justddumbly display it and handle events when the user presses it. smaller > > than full efl but not totally minimal. > > 3. do it all yourself at the lowest levesl. as small as it will get but by > > far the most amount of work for you. > > Thanks for this nice overview. > > I would like to try it in that order and see how useable it is speed wise and > if it's too slow then move to the next variant and remove one layer of > abstraction. > > For now I am working with option 1. As I said in my first mail it would be > nice to use the same technology just with a different backend and therefore > reuse all the work you and others have put into it. > > Option 3 (although probably not as low level as you described it) is what > kexecboot does. It would therefore be an option to add touchscreen support to > kexecboot. I would probably not be as pretty as an elementary based solution > if there are people who actually care about the optical aspect of the thing. sure. as i said. options. #3 is by far the most work with the least visual appealing results. #2 is probably a nice half-way-house. :) > > > Proof of Concept > > > ================ > > > > > > As a proof of concept I started to write a simple shell script (well > > > in the beginning it was simple in the meantime it evolved in kind of > > > mini build system, maybe something like OpenWRT could be used but I > > > wanted a simple solution where I actually understand what's going on) > > > which downloads and cross compiles everything with an uclibc based > > > toolchain. > > > > > > So far I have cross compiled all the components mentioned in this > > > post the result is about 6-7MB large. > > > > > > I then tried to run the elementary dialog application from the > > > elementary wiki page[3] in a chrooted system and this works > > > (although there seems to be a problem with the touchscreen which > > > doesn't quite work right and sometimes even causes a segfault). > > > > do you have ts calibration working? > > Don't know yet, I have just copied over the ts.conf from SHR so that it at > least uses the same/right modules. Touchscreen calibration is the next thing > I need to look into. Because I tested this in a chroot from within a SHR > system I thought the touchscreen would already be in a redy-to-use state (i.e > calibrated) is this a wrong assumption? ok. chances are a pre-calibrated file will be ok. but if u want to work on multiple devices (not just a freerunner and in the end this is a goal you should have in mind as there will be more devices with different sized screens, etc. etc. and its good to plan ahead). > Anyone want to share a known to work receipt for touchscreen calibration on > the Freerunner? > > > you may actually have problems here in that > > if the ts is not calibrated and u dont have the right calibration data, it > > may not be totally useful. but this depends from device to device. as for > > segv. backtraces please! :) > > Will have to reproduce it later on. > > Thanks for your comments. > > Marc > > -- > Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [hidden email] _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
|
Marc Andre Tanner
|
On Sat, Oct 10, 2009 at 12:14:02AM +1100, Carsten Haitzler wrote:
> On Fri, 9 Oct 2009 13:00:12 +0200 Marc Andre Tanner <[hidden email]> > said: > > On Fri, Oct 09, 2009 at 02:35:14PM +1100, Carsten Haitzler wrote: > > > On Thu, 8 Oct 2009 22:50:00 +0200 Marc Andre Tanner > > > > - GUI based on elementary with framebuffer support? > > > > > > > > In theory this would be the best solution because we would > > > > use the same technology as in a normal system just with a > > > > different backend. This should ensure that it's actually > > > > finger friendly. Although text entry remains a problem > > > > because the illume keyboard can't be used. But I hope that > > > > text entry won't be necessary anyway (no kernel command line > > > > changes through the GUI, sorry ;) In practice I don't know > > > > how mature the framebuffer backend actually is and it has > > > > quite a few dependcies[2]: > > > > > > > > * eina > > > > * eet > > > > o zlib > > > > o libjpeg > > > > * evas > > > > o freetype > > > > > > i think you missed fontconfig - though it is optional, all the default > > > themes for elementary etc. assume fontconfig support for font naming. > > > > Ok now I am confused. Evas actually has support for reading fonts.{dir,alias} > > files and doesn't require fontconfig for this. Doesn't this work the way I > > think it does? > > oh wait. sorry. fonts.dir and fonts.alias are built-in. they are old x-stile > font naming schemes. its a simple parser. fontconfig provides things like Sans > etc. normally. i've actually totally forgotten about that code. it's ancient. > interesting that it still works! :) Ok, I have to admit my knowledge about fonts is basically inexistent. Does this mean the fonts.{dir,alias} files are useless because the mapping for special styles like bold/italic doesn't work? And I need fontconfig for these? I probably don't need special styles anyway and I certainly don't find the idea of storing font configuration in XML that appealing... > > > > * ecore > > > > o ecore-file > > > > o ecore-evas > > > > o ecore-input > > > > o ecore-job > > > > o ecore-txt > > > > o libiconv (functionality can be provided by uClibc) > > > > o tslib > > > > * edje > > > > o embryo > > > > o lua > > > > * libpng > > > > > > nb. u can drop libpng. if all your image data is inside edje files (or u can > > > put it inot .eet files too) then you won't need this. > > > > I added libpng because I saw that the default elementary themes uses png files > > and I thought it needs some way to read them, thus libpng. > > the theme does. but its compiled into a .edj file. once there it is no longer > png :) no need for png.. unless u - un your app, specify png files for things :) > Thanks for the clarification I'm starting to understand how this all works. So if I want to load an external logo from the SD card I would need a image library. Since libjpeg is already a dependency of eet I could just require that the system images provide an jpeg logo and libpng can go away. Just out of interest: how is the image stored in the .edj file? Since eet depends on libjpeg is it reencoded as jpeg? > > > > I have cross compiled all this and without any special optimisation > > > > (I just disabled everything in ./configure which seemed not critical) > > > > the whole system is about 6-7MB large this is without the kernel. > > > > > > indeed. > > > > As a said this is without any optimization, no special compilation flags, > > nothing. I should try to link everything statically which has 2 main > > advantages: > > you will save very little with things like -Os. maybe 5-10%. on a good day. > that ballpark. Newer gcc's support whole build optimization that is you basically compile an entire project with one gcc inovacation. It will use lots of memory at compile time but because it has more knowledge about the whole project and how the different parts work together it can use more advanced optimization techniques which should result in smaller/more efficient code. Anyway this is the theory I will see how this works in practice. There are enough other things to improve before I even want to start with this kind of thing. > > - the linker should be able to remove any code paths which aren't actually > > used. > > not from share libraries. only if you statically compile with executables. That's what I meant. I would statically compile my bootmenu app and just copy that over to the rootfs. > > - at runtime the dynamic linker doesn't have to load all the libraries > > (less I/O + code relocation) which should speed up the application start. > > > > > > I am not familiar with the EFL code base but what I have seen > > > > so far seems like it isn't really optimized for size. So there could > > > > be some potential although it would require some work and upstream > > > > approval. > > > > > > > > Maybe the idea to use elementary is overkill but what are the > > > > alternatives? > > > > > > i'll shime in here. yes. efl has grown over the years, and well - the more > > > functionality you want, the more space it will take. if you are hell-bent on > > > smallest size you possibly would just write your own fb gui that is very > > > simple and ugly (with white/black boxes for example). > > > > I know that elf provides a lot of features and is rather small for what it > > does (don't get me started on gtk or qt). But what suprised me for example > > was that although I had compiled elementary with just the framebuffer backend > > it nevertheless tried to use the X backend unless it was told to not do so > > (with ELM_ENGINE=fb). So there apparently is code there which strictly > > speaking doesn't has to be there. > > x11 engine is the default. thats just how the code is. :) if its not coimpiled > in you just get stubs trying to use the engine and returning 0 saying they > cant (ie nothing compiled in) you wont save more than a dozen or 2 bytes by > trying to remove these stubs entirely. its not worth it. Ok that's probably true, I was just arguing from the busybox mindset where a few bytes are actually a worthwhile saving ;) > > Another thing is the lua/embryo thing. If I am not mistaken they basically do > > the same thing so it should be possible to only use one of the two. Lua was > > added recently and should become the default, right? So embryo will go away in > > the long run, correct? But I guess it will be needed for backwards > > compatibility anyway so in my opinion it should be possible to disable lua at > > compile time. > > there .. no. embryo is there because it is a default feature of edje. lua is as > of recently also a default feature. it is required because all edje files are > equally capable. i do not want an edje that "might not work with some edje > files". it's not going to happen because as policy i want all edje files and > themes to work the same everywhere. not fail or work stangely because someone > happend to build without the support somewhere. thus you will need both. note. > embryo is TINY. its runtime library is on the order of about 40kb. thats the > footprint. the bits in edje that hook to it might be another 10kb of code at > worst. lua is much bigger - but we are now using it because it saves us work > and adds more power. it's not fully up and ready yet, but it will be. so you're > getting both embryo and lua. one way or another. > > (not embryo script is compiled to bytecode and put into the .edj files. its is > VERY fast to execute. about 2x faster than java. it wil be many times faster > than lua to execute the same logic, so as long as you want just simple logic - > use embryo script. if u want to get more complex and imaginative.. then u want > lua - so there is a very good reason to keep both. efficiency) Again thanks for the clarification. I understand your point of view regarding ejde files which should work everywhere to a certain degree. On the other hand I think that the peoples who actually use lua could enable it on their own, or there should at least be the possibility to disable it. Afterall special environments like the one we are talking about here don't need it. I guess I could either use an older svn snapshot before the lua merge (I don't like this option because it of course means bugs wont be fixed in my version) or patch it manually out (don't know how complicated that would be). > > > to reduce complexity i would even remove fonts. what i'd do is: > > > > > > 1. every bootable os provides as well as kernel in /boot/zImage (or > > > wherever), it provides a /boot/bootIcon - this is a simple zlib compressed > > > (see zlib docs on how to simply give it a chunk of data to compress, or > > > decompress). you could avoid compression if u want, but i think this would > > > be worthwhile. lets say the icon data is RGBA (lets use a universal format > > > to account for different devices with different screen depths/formats). > > > aany bootable os must provide this file or it wont be listed. (yes it's an > > > added requirementm but moving work to the bootable os's i takes it out of > > > the qui boot image) > > > 2. within the qui boot fs u include some /boot/wallpaper file - same format > > > as icons. > > > 3. you load wallpaper, convert to screen depth in the simplest/dumbest way > > > (speed isnt important. you are not doing realtime ui rendering). eg for > > > 16bpp this would be: > > > > > > unsigned int *inpix; > > > unsigned short *outpix; > > > > > > *outpix = (((*inpix & 0xff0000) >> 19) << 11) | (((*inpix & 0xff00) >> 10) > > > << > > > 5) | ((*inpix & 0xff) >> 3); > > > > > > i'll leave it up to you to handle other screen formats (32, 24, 18, 15, 12, > > > 8bpp etc.). but one per format. > > > > > > now blend the icons u find (u'll probably just want to blend agaibnst the > > > original rgba wallpaper image and then convert thr result to screen format > > > like above - see google for alpha blending math. its rather simple. it's > > > easy to do, its much more work to do FAST. here speed isnt important as u > > > are just going to render this once and put it up - no realtime ui), one at > > > a time on the screen eg: > > > > > > +-------------+ > > > | | > > > | [ 1 ] [ 2 ] | > > > | | > > > | [ 3 ] [ 4 ] | > > > | | > > > | [ 5 ] [ 6 ] | > > > | | > > > +-------------+ > > > ... etc. > > > > > > as many as the screen fits - the icons themselves can just be an image (eg a > > > penguin) or image + text. u'll probably want to use tslib and get coords > > > when u press to see if up press on one of them - then boot that. you should > > > adjust the layout based on screen size. eg for landscape: > > > > > > +-------------------+ > > > | | > > > | [ 1 ] [ 2 ] [ 3 ] | > > > | | > > > | [ 4 ] [ 5 ] [ 6 ] | > > > | | > > > +-------------------+ > > > > > > this will provide all you need for a grahical boot. it wont be smooth. it > > > wont scroll or animate. it wont let you add much more complexity without a > > > lot of work (eg configuration panels or more than the above hyper-simple > > > boot), but it will function and be very small. > > > > Thanks for your insight. I think it's a little to low level for me right now, > > afterall I have a limited amount of time I can spend on this. The key is > > probably to get the right balance between the amount of work and usability / > > performance. For now I will leave some abstraction layers in and see how > > small/fast this can be made. > > > > > of course it's easy for me to say this. i've done all this kind of stuff > > > before. many times. in fact deep down inside efl are semblances of some of > > > this, as just a subset of all that efl does. but it does so much more so > > > it's not small. in return for that footprint you get a small mountain of > > > features. but as i said - easy for me to say the above. i can do it in my > > > sleep - it'sw hat i do, but it's up to you to decide if you are up to doing > > > it at this low level or not. for any reasonable app you'd end up using > > > enough of efl's features to make it worth carrying along its size. it'd be > > > worth the expense, but... for you i don't know if you will ever use all > > > those features. it may simply not be worth it. as long as u use efl your > > > image is not going to be that small. then again you are adding dropbear and > > > thus also enough network config tools to set up usbnet > > > > This should be covered by busybox i hope. > > hopefully, but every busybox feature added is more space. > > > > - what about wifi? wireless tools too? how much is the > > > > Not going to happen (at least not by me). The network support is just to > > provide a kind of minimal rescue system to ssh in over usb, mount the sd card > > and then chroot into the regular system to fix something. It's not intended > > to get some kernel + root filesystem from a NFS server over wifi. Anyway if > > the usb network support should be the few KBs which make it to large/slow > > then I will probably drop them. > > ok. > > > > image size when you remove any of the ui bits - all your other parts (libc, > > > busybox, dropbear, network tools to bring up usbnet and/or wifi, wireless > > > tools, dhclient if u have wifi... etc. first see how big that is. how big is > > > it? then relative to that, look at ui. > > > > I agree that this is the right approach. Antoher interesting thing is how much > > an aditional MB actually costs in terms of speed (copy from NAND to RAM). > > oh true. though it might work best as a real jffs or cramfs fs instead of > initrd - it's flash. you have no seek overhead so a linear read isnt going to > be much better than a sparse fetch of whats needed from jffs2 or cramfs. in > fact chancges are u'll be better off as u fecth "on demand" as opposed to read > everything even though some of it isnt needed. my suggestion might be cramfs as > its going to compress best. :) This would require that the kernel partition in NAND is formated as a filesystem but then Qi couldn't read from it. Or am missing something obvious here? > > Below is a listing of my current initramfs files sorted by size. Now that I > > compare them to my SHR system I see that they are a lot larger. For example > > libevas-* is only 687K on my SHR. I will have to investigate if this is just > > because of the missing optimization flags in my $CFLAGS or what causes this. > > ok. for option 1, u can nuke libpng. thats 224k gone. libecore_con should be > able to go. i can't think of a reason you need it. I enabled it because it seemed like ecore-file was going to need it. I will recheck this. > another 44k gone. the > evas jpeg image loader can go. another 20k. I guess I will need this if I want to load logo's from the SD card. > all the saver modules for evas can go I didn't find a way to disable them during ./configure should I just not copy them over to the rootfs? > and the png loader. thats a total of 32k gone. Yay! > now elementary's default them > can be very much trimmed. it has images - a fair few in it. if you used fewer > images and smaller ones that were much simpler and re-used a lot, it'd make it > smaller. you could get that default theme down to maybe 50-100k without much > trouble. As my designer skills are < 0 I will leave this as is for now. >also you use DejaVuSans.ttf - its HUGE. Yes I just used it to test the font issue thing I posted about on e-devel. > it has lots of chars for all > sorts of international text (outside of latin/western european). the standard > and much smaller Vera.ttf is only 72k. (DejaVu was a modified Vera with all > these extra chars added). so you could save 512k by using plain old vera > instead (this i think has western european accented chars like ö and é œ ß etc. > so u could even handle that, but for a bootloader i suspect normal > lasting/ascii is just fine. right?). Of course plain ascii is enough. I will switch to Vera.ttf. > so.. lets see. for your #1 i can find 224+44+20+32+512k of savings without > changing any functionality or doing any real work except deleting files. that's > 832k to squeeze out there. you can add another probably 250k of savings if u > spend time in making a very lean theme. so we're about 1.1mb now to lose (of > uncomrpessed files - and of course this is rounding up all files to 4k blocks > of savings may be a little less). > > now if u did option #2 and did a lower level ui with no text (text in the > icons) just with evas + ecore-evas, you could save an extra (on top of the > total savings above) if you put png loader back but remove eet (this means u > dont need libjpeg anymore), so... +224 -272 -108 -648 -72 -384 -78 -44 -8 +8 > (trust me on this) ... another 1382k of savings on top of the reduction in #1. > > in #2 efl itself will have a footrpint of 928+448+224+168+100+84+28+24+24+16+16 > +32+8+8+8+8+4+4+4+4... 2100kb. so thats efl's footprint (approximately) in > addition to a minimal core os. thats whgat it costs you in space for efl to > save you work for #2 - of course #1 will cost an extra 1382kb on top of this Thanks for the calculations :) So for now I hope that those 1382kb won't have that much of an impact. > so that is about the best i can do for you. note these numebers are > uncomrpessed. comrprssed expect the numebrs to about halve. ie efl costs u > about 1mb of "storage" as after compression thats what u'll get. elementary, > edje and friends will cost u another about 700k on top. based on your numbers > below. :) that's not a hell of a lot. I agree for what it does that's not a lot at all. [snip file sizes] > > > one thing i can suggest. you can drop edje and elementary and do this in > > > just ecore_evas + evas. you could even drop eet here. just 1 image format > > > loader (eg libpng), and you'd be able to i think have a subset of ecore > > > (ecore, ecore_evas, ecore_input, ecore_fb), and just evas + buffer, > > > software_generic and fb engine and just png loader module. no savers > > > modules. > > > > > > now you'd need to create all your own "widgets" - but you could stick to a > > > simple design as above just an array of icons. load the icon files (now u > > > can make them .png files in the boot dirs of the os's) and put them on the > > > screen. you can now easily add callbacks for the mouse down (or up really) > > > on each icon and boot the appropriate os. wallpaper can also be a png file > > > in the qui boot fs. you will be using efl at a lower level. you handle the > > > callbacks directly and place the objects yourself (and handle canvas > > > resizes - yes it can happen even on the fb. eg a resolution change, but in > > > general handling this right just handles the inital fb size right anyway). > > > this will mean you donthave to handle rendering code and different screen > > > formats, image loading or tslib interfacing etc. it should have you a much > > > reduced efl footprint. but keep you from the lowest ugliest bits. hell if > > > you keep all the "os info for the ui" inside the png font handling is moot. > > > u will still need freetype - but u just put name of the os image into the > > > icon itself (nothing 10 seconds in gimp cant do). > > > > > > so to repeat > > > > > > 1. either full efl, elementary etc. - but this will be a big footprint. > > > always > > > 2. subset of efl and keep your ui simple eg as i described above and punt > > > off all the os identification to a png icon as i described above and > > > justddumbly display it and handle events when the user presses it. smaller > > > than full efl but not totally minimal. > > > 3. do it all yourself at the lowest levesl. as small as it will get but by > > > far the most amount of work for you. > > > > Thanks for this nice overview. > > > > I would like to try it in that order and see how useable it is speed wise and > > if it's too slow then move to the next variant and remove one layer of > > abstraction. > > > > For now I am working with option 1. As I said in my first mail it would be > > nice to use the same technology just with a different backend and therefore > > reuse all the work you and others have put into it. > > > > Option 3 (although probably not as low level as you described it) is what > > kexecboot does. It would therefore be an option to add touchscreen support to > > kexecboot. I would probably not be as pretty as an elementary based solution > > if there are people who actually care about the optical aspect of the thing. > > sure. as i said. options. #3 is by far the most work with the least visual > appealing results. #2 is probably a nice half-way-house. :) > > > > > Proof of Concept > > > > ================ > > > > > > > > As a proof of concept I started to write a simple shell script (well > > > > in the beginning it was simple in the meantime it evolved in kind of > > > > mini build system, maybe something like OpenWRT could be used but I > > > > wanted a simple solution where I actually understand what's going on) > > > > which downloads and cross compiles everything with an uclibc based > > > > toolchain. > > > > > > > > So far I have cross compiled all the components mentioned in this > > > > post the result is about 6-7MB large. > > > > > > > > I then tried to run the elementary dialog application from the > > > > elementary wiki page[3] in a chrooted system and this works > > > > (although there seems to be a problem with the touchscreen which > > > > doesn't quite work right and sometimes even causes a segfault). > > > > > > do you have ts calibration working? > > > > Don't know yet, I have just copied over the ts.conf from SHR so that it at > > least uses the same/right modules. Touchscreen calibration is the next thing > > I need to look into. Because I tested this in a chroot from within a SHR > > system I thought the touchscreen would already be in a redy-to-use state (i.e > > calibrated) is this a wrong assumption? > > ok. chances are a pre-calibrated file will be ok. but if u want to work on > multiple devices (not just a freerunner and in the end this is a goal you > should have in mind as there will be more devices with different sized screens, > etc. etc. and its good to plan ahead). True. Thanks, Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
|
Carsten Haitzler (The Rasterman)-2
|
On Fri, 9 Oct 2009 17:14:30 +0200 Marc Andre Tanner <[hidden email]>
said: > On Sat, Oct 10, 2009 at 12:14:02AM +1100, Carsten Haitzler wrote: > > On Fri, 9 Oct 2009 13:00:12 +0200 Marc Andre Tanner > > <[hidden email]> said: > > > On Fri, Oct 09, 2009 at 02:35:14PM +1100, Carsten Haitzler wrote: > > > > On Thu, 8 Oct 2009 22:50:00 +0200 Marc Andre Tanner > > > > > - GUI based on elementary with framebuffer support? > > > > > > > > > > In theory this would be the best solution because we would > > > > > use the same technology as in a normal system just with a > > > > > different backend. This should ensure that it's actually > > > > > finger friendly. Although text entry remains a problem > > > > > because the illume keyboard can't be used. But I hope that > > > > > text entry won't be necessary anyway (no kernel command line > > > > > changes through the GUI, sorry ;) In practice I don't know > > > > > how mature the framebuffer backend actually is and it has > > > > > quite a few dependcies[2]: > > > > > > > > > > * eina > > > > > * eet > > > > > o zlib > > > > > o libjpeg > > > > > * evas > > > > > o freetype > > > > > > > > i think you missed fontconfig - though it is optional, all the default > > > > themes for elementary etc. assume fontconfig support for font naming. > > > > > > Ok now I am confused. Evas actually has support for reading fonts. > > > {dir,alias} files and doesn't require fontconfig for this. Doesn't this > > > work the way I think it does? > > > > oh wait. sorry. fonts.dir and fonts.alias are built-in. they are old x-stile > > font naming schemes. its a simple parser. fontconfig provides things like > > Sans etc. normally. i've actually totally forgotten about that code. it's > > ancient. interesting that it still works! :) > > Ok, I have to admit my knowledge about fonts is basically inexistent. > > Does this mean the fonts.{dir,alias} files are useless because the mapping for > special styles like bold/italic doesn't work? And I need fontconfig for these? > I probably don't need special styles anyway and I certainly don't find the > idea of storing font configuration in XML that appealing... they only work in a very basic way - pretty much to create x-ish mappings to font files but primarily aliases. you wont be able to use them to do Sans:style=Bold. that is fontconfig. fontconfig is the xml beastie. > > > > > * ecore > > > > > o ecore-file > > > > > o ecore-evas > > > > > o ecore-input > > > > > o ecore-job > > > > > o ecore-txt > > > > > o libiconv (functionality can be provided by uClibc) > > > > > o tslib > > > > > * edje > > > > > o embryo > > > > > o lua > > > > > * libpng > > > > > > > > nb. u can drop libpng. if all your image data is inside edje files (or > > > > u can put it inot .eet files too) then you won't need this. > > > > > > I added libpng because I saw that the default elementary themes uses png > > > files and I thought it needs some way to read them, thus libpng. > > > > the theme does. but its compiled into a .edj file. once there it is no > > longer png :) no need for png.. unless u - un your app, specify png files > > for things :) > > > > Thanks for the clarification I'm starting to understand how this all works. > > So if I want to load an external logo from the SD card I would need a image > library. Since libjpeg is already a dependency of eet I could just require > that the system images provide an jpeg logo and libpng can go away. cxorrect. tho that means logos cant have transparency. they are solid blocks of pixels. not sure everyone will want this. you could allow logos as .edj files which would big the biggest flexibility for you, as this can be a single image or a combination of image and text, animation and more. this does raise the bar for the images to have to generate .edj files. but if you are happy with this, this gives you the easies work for oyu and the greatest power/flexibility. > Just out of interest: how is the image stored in the .edj file? Since eet > depends on libjpeg is it reencoded as jpeg? depends. LOSSY compression uses jpeg. it ALSO allows for an alpha channel, unlike jpeg itself. it basically stores alpha as an extra greyscale jpeg as well. for COMP compression the pixels are just passed through zlib (basically gzip) for lossless compression. this works quite wel for artifcially drawn icons that have solid colours, outlines or gradients. eet itself takes care of all of this for you - it just takes RGBA pixles on encode and presents them back to you on decode > > > > > I have cross compiled all this and without any special optimisation > > > > > (I just disabled everything in ./configure which seemed not > > > > > critical) the whole system is about 6-7MB large this is without the > > > > > kernel. > > > > > > > > indeed. > > > > > > As a said this is without any optimization, no special compilation flags, > > > nothing. I should try to link everything statically which has 2 main > > > advantages: > > > > you will save very little with things like -Os. maybe 5-10%. on a good day. > > that ballpark. > > Newer gcc's support whole build optimization that is you basically compile an > entire project with one gcc inovacation. It will use lots of memory at compile > time but because it has more knowledge about the whole project and how the > different parts work together it can use more advanced optimization techniques > which should result in smaller/more efficient code. Anyway this is the theory > I will see how this works in practice. There are enough other things to > improve before I even want to start with this kind of thing. thats possible when making 1 executable. it's not possible to strip shared libraries of code "not used by apps" as these are completely separate builds, elements and more. example - evas will hve code for handling 8bit color displays. nothing will ever make gcc get rid of it ... unless you statially compile. even then it wont as evas runtime will chose conversion code based on screen configuration... which gcc doesnt know. this is why evas has so many --enable and --disable options for configure - uc an disable vast blobs of support for things you dont need - like 8 bit and 24/32, 15bit, 12bit and 18bit displays. look at configure --help for evas. > > > - the linker should be able to remove any code paths which aren't > > > actually used. > > > > not from share libraries. only if you statically compile with executables. > > That's what I meant. I would statically compile my bootmenu app and just copy > that over to the rootfs. then you wont need libevas etc. - it'd end up being a single binary. > > > - at runtime the dynamic linker doesn't have to load all the libraries > > > (less I/O + code relocation) which should speed up the application > > > start. > > > > > > > > I am not familiar with the EFL code base but what I have seen > > > > > so far seems like it isn't really optimized for size. So there > > > > > could be some potential although it would require some work and > > > > > upstream approval. > > > > > > > > > > Maybe the idea to use elementary is overkill but what are the > > > > > alternatives? > > > > > > > > i'll shime in here. yes. efl has grown over the years, and well - the > > > > more functionality you want, the more space it will take. if you are > > > > hell-bent on smallest size you possibly would just write your own fb > > > > gui that is very simple and ugly (with white/black boxes for example). > > > > > > I know that elf provides a lot of features and is rather small for what it > > > does (don't get me started on gtk or qt). But what suprised me for example > > > was that although I had compiled elementary with just the framebuffer > > > backend it nevertheless tried to use the X backend unless it was told to > > > not do so (with ELM_ENGINE=fb). So there apparently is code there which > > > strictly speaking doesn't has to be there. > > > > x11 engine is the default. thats just how the code is. :) if its not > > coimpiled in you just get stubs trying to use the engine and returning 0 > > saying they cant (ie nothing compiled in) you wont save more than a dozen > > or 2 bytes by trying to remove these stubs entirely. its not worth it. > > Ok that's probably true, I was just arguing from the busybox mindset where a > few bytes are actually a worthwhile saving ;) i am happy to spend bytes when it makes life simpler and easier in the bigger picture. :) > > > Another thing is the lua/embryo thing. If I am not mistaken they > > > basically do the same thing so it should be possible to only use one of > > > the two. Lua was added recently and should become the default, right? So > > > embryo will go away in the long run, correct? But I guess it will be > > > needed for backwards compatibility anyway so in my opinion it should be > > > possible to disable lua at compile time. > > > > there .. no. embryo is there because it is a default feature of edje. lua > > is as of recently also a default feature. it is required because all edje > > files are equally capable. i do not want an edje that "might not work with > > some edje files". it's not going to happen because as policy i want all > > edje files and themes to work the same everywhere. not fail or work > > stangely because someone happend to build without the support somewhere. > > thus you will need both. note. embryo is TINY. its runtime library is on > > the order of about 40kb. thats the footprint. the bits in edje that hook to > > it might be another 10kb of code at worst. lua is much bigger - but we are > > now using it because it saves us work and adds more power. it's not fully > > up and ready yet, but it will be. so you're getting both embryo and lua. > > one way or another. > > > > (not embryo script is compiled to bytecode and put into the .edj files. its > > is VERY fast to execute. about 2x faster than java. it wil be many times > > faster than lua to execute the same logic, so as long as you want just > > simple logic - use embryo script. if u want to get more complex and > > imaginative.. then u want lua - so there is a very good reason to keep > > both. efficiency) > > Again thanks for the clarification. I understand your point of view regarding > ejde files which should work everywhere to a certain degree. On the other > hand I think that the peoples who actually use lua could enable it on their > own, or there should at least be the possibility to disable it. Afterall > special environments like the one we are talking about here don't need it. but that's not going to happen. :) not for edje. i dont want it becoming that where some feature may or may not work depending on how it was compiled. people will download themes, icons, wallpapers etc. and find they appear nothing like advertised, break, do bizarre things just because some feature was not compiled in. i dont intend to make it easy by making it optional. i highly discourage it being patched out. i have been doing open source, linux and e for more than a decade and i know where many of the questions end up - they end up on my table asking about something someone else patched and modified. to simply avoid the pain of having to 1. figure why things are not working 2. having to explain what may have been done, and 3. have to finally redirect the queries to the people doing the patching. :) lua and embryo are non-negotiable features of edje. jut like text, images and rectangles are non-optional features of evas, etc. etc. :) > I guess I could either use an older svn snapshot before the lua merge (I don't > like this option because it of course means bugs wont be fixed in my version) > or patch it manually out (don't know how complicated that would be). as above. you will create problems for yourself. you use elementary. elementary has themes. themes are edje files. they are designed and intended to be replaceable. people can/will replace do it. and they will then complain why theme x, y, z etc. that uses lua "has bugs". from upstream it will be documented that all edje files can do this. all. no conditions. :) > > > > to reduce complexity i would even remove fonts. what i'd do is: > > > > > > > > 1. every bootable os provides as well as kernel in /boot/zImage (or > > > > wherever), it provides a /boot/bootIcon - this is a simple zlib > > > > compressed (see zlib docs on how to simply give it a chunk of data to > > > > compress, or decompress). you could avoid compression if u want, but i > > > > think this would be worthwhile. lets say the icon data is RGBA (lets > > > > use a universal format to account for different devices with different > > > > screen depths/formats). aany bootable os must provide this file or it > > > > wont be listed. (yes it's an added requirementm but moving work to the > > > > bootable os's i takes it out of the qui boot image) > > > > 2. within the qui boot fs u include some /boot/wallpaper file - same > > > > format as icons. > > > > 3. you load wallpaper, convert to screen depth in the simplest/dumbest > > > > way (speed isnt important. you are not doing realtime ui rendering). eg > > > > for 16bpp this would be: > > > > > > > > unsigned int *inpix; > > > > unsigned short *outpix; > > > > > > > > *outpix = (((*inpix & 0xff0000) >> 19) << 11) | (((*inpix & 0xff00) >> > > > > 10) << > > > > 5) | ((*inpix & 0xff) >> 3); > > > > > > > > i'll leave it up to you to handle other screen formats (32, 24, 18, 15, > > > > 12, 8bpp etc.). but one per format. > > > > > > > > now blend the icons u find (u'll probably just want to blend agaibnst > > > > the original rgba wallpaper image and then convert thr result to screen > > > > format like above - see google for alpha blending math. its rather > > > > simple. it's easy to do, its much more work to do FAST. here speed isnt > > > > important as u are just going to render this once and put it up - no > > > > realtime ui), one at a time on the screen eg: > > > > > > > > +-------------+ > > > > | | > > > > | [ 1 ] [ 2 ] | > > > > | | > > > > | [ 3 ] [ 4 ] | > > > > | | > > > > | [ 5 ] [ 6 ] | > > > > | | > > > > +-------------+ > > > > ... etc. > > > > > > > > as many as the screen fits - the icons themselves can just be an image > > > > (eg a penguin) or image + text. u'll probably want to use tslib and get > > > > coords when u press to see if up press on one of them - then boot that. > > > > you should adjust the layout based on screen size. eg for landscape: > > > > > > > > +-------------------+ > > > > | | > > > > | [ 1 ] [ 2 ] [ 3 ] | > > > > | | > > > > | [ 4 ] [ 5 ] [ 6 ] | > > > > | | > > > > +-------------------+ > > > > > > > > this will provide all you need for a grahical boot. it wont be smooth. > > > > it wont scroll or animate. it wont let you add much more complexity > > > > without a lot of work (eg configuration panels or more than the above > > > > hyper-simple boot), but it will function and be very small. > > > > > > Thanks for your insight. I think it's a little to low level for me right > > > now, afterall I have a limited amount of time I can spend on this. The > > > key is probably to get the right balance between the amount of work and > > > usability / performance. For now I will leave some abstraction layers in > > > and see how small/fast this can be made. > > > > > > > of course it's easy for me to say this. i've done all this kind of stuff > > > > before. many times. in fact deep down inside efl are semblances of some > > > > of this, as just a subset of all that efl does. but it does so much > > > > more so it's not small. in return for that footprint you get a small > > > > mountain of features. but as i said - easy for me to say the above. i > > > > can do it in my sleep - it'sw hat i do, but it's up to you to decide if > > > > you are up to doing it at this low level or not. for any reasonable app > > > > you'd end up using enough of efl's features to make it worth carrying > > > > along its size. it'd be worth the expense, but... for you i don't know > > > > if you will ever use all those features. it may simply not be worth it. > > > > as long as u use efl your image is not going to be that small. then > > > > again you are adding dropbear and thus also enough network config tools > > > > to set up usbnet > > > > > > This should be covered by busybox i hope. > > > > hopefully, but every busybox feature added is more space. > > > > > > - what about wifi? wireless tools too? how much is the > > > > > > Not going to happen (at least not by me). The network support is just to > > > provide a kind of minimal rescue system to ssh in over usb, mount the sd > > > card and then chroot into the regular system to fix something. It's not > > > intended to get some kernel + root filesystem from a NFS server over > > > wifi. Anyway if the usb network support should be the few KBs which make > > > it to large/slow then I will probably drop them. > > > > ok. > > > > > > image size when you remove any of the ui bits - all your other parts > > > > (libc, busybox, dropbear, network tools to bring up usbnet and/or wifi, > > > > wireless tools, dhclient if u have wifi... etc. first see how big that > > > > is. how big is it? then relative to that, look at ui. > > > > > > I agree that this is the right approach. Antoher interesting thing is how > > > much an aditional MB actually costs in terms of speed (copy from NAND to > > > RAM). > > > > oh true. though it might work best as a real jffs or cramfs fs instead of > > initrd - it's flash. you have no seek overhead so a linear read isnt going > > to be much better than a sparse fetch of whats needed from jffs2 or cramfs. > > in fact chancges are u'll be better off as u fecth "on demand" as opposed > > to read everything even though some of it isnt needed. my suggestion might > > be cramfs as its going to compress best. :) > > This would require that the kernel partition in NAND is formated as a > filesystem but then Qi couldn't read from it. Or am missing something obvious > here? the fs can be mounted as an offset from the start of a partition. you cn even split it into 2 partitions. 1 for kernel, 1 for rootfs. as such qi SHOULD be able to technically - it can read krenels from a FILESYSTEM on sd. it can read fs's. no reason it cant read an fs from nand too (in principle) other than simply that having not been written in or explicitly avoided (can't think of a good reason myself if u handle fs's already). > > > Below is a listing of my current initramfs files sorted by size. Now that > > > I compare them to my SHR system I see that they are a lot larger. For > > > example libevas-* is only 687K on my SHR. I will have to investigate if > > > this is just because of the missing optimization flags in my $CFLAGS or > > > what causes this. > > > > ok. for option 1, u can nuke libpng. thats 224k gone. libecore_con should be > > able to go. i can't think of a reason you need it. > > I enabled it because it seemed like ecore-file was going to need it. I will > recheck this. oh yeah. i forgot. the ecore_file_download stuff uses it. :) > > another 44k gone. the > > evas jpeg image loader can go. another 20k. > > I guess I will need this if I want to load logo's from the SD card. if they are jpeg. if they are png - u'd need png loader. if u put them in edje files, u need nothing. u already have support. > > all the saver modules for evas can go > > I didn't find a way to disable them during ./configure should I just not copy > them over to the rootfs? just delete the modules. the way it builds - its intended to just install and then have package builds split the install up into sub-sections, like a package for each loader and each saver module, each engine etc. so just delete the stuff u dont need. > > and the png loader. thats a total of 32k gone. > > Yay! > > > now elementary's default them > > can be very much trimmed. it has images - a fair few in it. if you used > > fewer images and smaller ones that were much simpler and re-used a lot, > > it'd make it smaller. you could get that default theme down to maybe > > 50-100k without much trouble. > > As my designer skills are < 0 I will leave this as is for now. welljust lettign u know there is space to be saved. and be prepared - the elementary theme WILL getbigger over time. the default theme is expected to provide every feature elementary has. thus everything elm can have - it will get. :) > >also you use DejaVuSans.ttf - its HUGE. > > Yes I just used it to test the font issue thing I posted about on e-devel. > > > it has lots of chars for all > > sorts of international text (outside of latin/western european). the > > standard and much smaller Vera.ttf is only 72k. (DejaVu was a modified > > Vera with all these extra chars added). so you could save 512k by using > > plain old vera instead (this i think has western european accented chars > > like ö and é œ ß etc. so u could even handle that, but for a bootloader i > > suspect normal lasting/ascii is just fine. right?). > > Of course plain ascii is enough. I will switch to Vera.ttf. > > > so.. lets see. for your #1 i can find 224+44+20+32+512k of savings without > > changing any functionality or doing any real work except deleting files. > > that's 832k to squeeze out there. you can add another probably 250k of > > savings if u spend time in making a very lean theme. so we're about 1.1mb > > now to lose (of uncomrpessed files - and of course this is rounding up all > > files to 4k blocks of savings may be a little less). > > > > now if u did option #2 and did a lower level ui with no text (text in the > > icons) just with evas + ecore-evas, you could save an extra (on top of the > > total savings above) if you put png loader back but remove eet (this means u > > dont need libjpeg anymore), so... +224 -272 -108 -648 -72 -384 -78 -44 -8 +8 > > (trust me on this) ... another 1382k of savings on top of the reduction in > > #1. > > > > in #2 efl itself will have a footrpint of 928+448+224+168+100+84+28+24+24+16 > > +16 +32+8+8+8+8+4+4+4+4... 2100kb. so thats efl's footprint (approximately) > > in addition to a minimal core os. thats whgat it costs you in space for efl > > to save you work for #2 - of course #1 will cost an extra 1382kb on top of > > this > > Thanks for the calculations :) So for now I hope that those 1382kb won't have > that much of an impact. > > > so that is about the best i can do for you. note these numebers are > > uncomrpessed. comrprssed expect the numebrs to about halve. ie efl costs u > > about 1mb of "storage" as after compression thats what u'll get. elementary, > > edje and friends will cost u another about 700k on top. based on your > > numbers below. :) that's not a hell of a lot. > > I agree for what it does that's not a lot at all. > > [snip file sizes] > > > > > one thing i can suggest. you can drop edje and elementary and do this in > > > > just ecore_evas + evas. you could even drop eet here. just 1 image > > > > format loader (eg libpng), and you'd be able to i think have a subset > > > > of ecore (ecore, ecore_evas, ecore_input, ecore_fb), and just evas + > > > > buffer, software_generic and fb engine and just png loader module. no > > > > savers modules. > > > > > > > > now you'd need to create all your own "widgets" - but you could stick > > > > to a simple design as above just an array of icons. load the icon files > > > > (now u can make them .png files in the boot dirs of the os's) and put > > > > them on the screen. you can now easily add callbacks for the mouse down > > > > (or up really) on each icon and boot the appropriate os. wallpaper can > > > > also be a png file in the qui boot fs. you will be using efl at a lower > > > > level. you handle the callbacks directly and place the objects yourself > > > > (and handle canvas resizes - yes it can happen even on the fb. eg a > > > > resolution change, but in general handling this right just handles the > > > > inital fb size right anyway). this will mean you donthave to handle > > > > rendering code and different screen formats, image loading or tslib > > > > interfacing etc. it should have you a much reduced efl footprint. but > > > > keep you from the lowest ugliest bits. hell if you keep all the "os > > > > info for the ui" inside the png font handling is moot. u will still > > > > need freetype - but u just put name of the os image into the icon > > > > itself (nothing 10 seconds in gimp cant do). > > > > > > > > so to repeat > > > > > > > > 1. either full efl, elementary etc. - but this will be a big footprint. > > > > always > > > > 2. subset of efl and keep your ui simple eg as i described above and > > > > punt off all the os identification to a png icon as i described above > > > > and justddumbly display it and handle events when the user presses it. > > > > smaller than full efl but not totally minimal. > > > > 3. do it all yourself at the lowest levesl. as small as it will get but > > > > by far the most amount of work for you. > > > > > > Thanks for this nice overview. > > > > > > I would like to try it in that order and see how useable it is speed wise > > > and if it's too slow then move to the next variant and remove one layer > > > of abstraction. > > > > > > For now I am working with option 1. As I said in my first mail it would be > > > nice to use the same technology just with a different backend and > > > therefore reuse all the work you and others have put into it. > > > > > > Option 3 (although probably not as low level as you described it) is what > > > kexecboot does. It would therefore be an option to add touchscreen > > > support to kexecboot. I would probably not be as pretty as an elementary > > > based solution if there are people who actually care about the optical > > > aspect of the thing. > > > > sure. as i said. options. #3 is by far the most work with the least visual > > appealing results. #2 is probably a nice half-way-house. :) > > > > > > > Proof of Concept > > > > > ================ > > > > > > > > > > As a proof of concept I started to write a simple shell script (well > > > > > in the beginning it was simple in the meantime it evolved in kind of > > > > > mini build system, maybe something like OpenWRT could be used but I > > > > > wanted a simple solution where I actually understand what's going on) > > > > > which downloads and cross compiles everything with an uclibc based > > > > > toolchain. > > > > > > > > > > So far I have cross compiled all the components mentioned in this > > > > > post the result is about 6-7MB large. > > > > > > > > > > I then tried to run the elementary dialog application from the > > > > > elementary wiki page[3] in a chrooted system and this works > > > > > (although there seems to be a problem with the touchscreen which > > > > > doesn't quite work right and sometimes even causes a segfault). > > > > > > > > do you have ts calibration working? > > > > > > Don't know yet, I have just copied over the ts.conf from SHR so that it at > > > least uses the same/right modules. Touchscreen calibration is the next > > > thing I need to look into. Because I tested this in a chroot from within > > > a SHR system I thought the touchscreen would already be in a redy-to-use > > > state (i.e calibrated) is this a wrong assumption? > > > > ok. chances are a pre-calibrated file will be ok. but if u want to work on > > multiple devices (not just a freerunner and in the end this is a goal you > > should have in mind as there will be more devices with different sized > > screens, etc. etc. and its good to plan ahead). > > True. > > Thanks, > Marc > > -- > Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [hidden email] _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
Paul Fertser
|
Carsten Haitzler (The Rasterman) <[hidden email]> writes:
>> This would require that the kernel partition in NAND is formated as a >> filesystem but then Qi couldn't read from it. Or am missing something obvious >> here? > > the fs can be mounted as an offset from the start of a partition. you cn even > split it into 2 partitions. 1 for kernel, 1 for rootfs. as such qi SHOULD be > able to technically - it can read krenels from a FILESYSTEM on sd. it can read > fs's. no reason it cant read an fs from nand too (in principle) other than > simply that having not been written in or explicitly avoided (can't think of a > good reason myself if u handle fs's already). And indeed Qi does read FSes from NAND. It uses ext2 factory partition to extract usb MAC. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:[hidden email] _______________________________________________ devel mailing list [hidden email] https://lists.openmoko.org/mailman/listinfo/devel |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
