[e-users] Really don't know how to start with
Hi all: I've been thinking porting elementary into my open source BIOS loader (coreboot), to beautify my BIOS setup menu, but I don't know how to start with. Because the BIOS loader are C code, build with Microsoft Visual C++ compiler, the first step I'm trying to do is to make elementary out of the box of MinGW, which is very hard. So I tried to build them with MinGW on my working machine (Windows 7) first, to observe the makefile and result, and to make a doable solution for MSVC10, but after following the instructions https://phab.enlightenment.org/w/windows/#windows-64-bits I keep failing on the autoconf section with errors like : configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." ". /../.." make: *** [builddir/efl] Error 1 I'm a real newbie to linux toolchains, stucked here for about two weeks... please help me with some tutorials, I'm really hitting the wall, thanks. -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
Since my BIOS has only about 8MB of space, I take Evas + Edje. May I ask what is pre-merge? And what really confuses me is I'm not porting it on any OS, just an environment with framebuffer support, so any OS based config would not work on my base, still working on stripping the code and figure out why MinGW always fails on me.. > Hi, > > this is quite of a hard task and I'd request you to evaluate the > requirements before digging much. How does coreboot behaves? How much space > do you have? > > Having it to compile should be the simplest task, but then you need to > implement the OS layers EFL expects in Ecore: main loop (timers, file > descriptors, ...), I/O (wayland, fb, x11)... Unless coreboot already > emulates a real OS, you'll have lots of work to do, maybe base yourself on > PSL1GHT work (PS3 native port). > > Also, EFL takes around 5mb by default, if you don't have that memory > (flash, RAM) you'll have extra work to strip it. > > My take on this is: get Evas (pre-merge) and port only it, integrate it > directly in coreboot. Base your UI in Expedite, as it looks okay using just > Evas, no other EFL. If you need to strip down, consider using Evas before > Eina, then you do not rely on other EFL. Yes, you'll end with a fork, but > your project just need a simple way to show graphics on screen, the extra > features of EFL are likely unneeded and will do more harm than good. > > > Regards, > -- Gustavo On Mon, Apr 29, 2013 at 6:55 PM, hYde wrote: > Hi all: > > I've been thinking porting elementary into my open source BIOS loader > (coreboot), to beautify my BIOS setup menu, but I don't know how to start > with. > > Because the BIOS loader are C code, build with Microsoft Visual C++ > compiler, the first step I'm trying to do is to make elementary out of the > box of MinGW, which is very hard. > > So I tried to build them with MinGW on my working machine (Windows 7) > first, to observe the makefile and result, and to make a doable solution > for MSVC10, but after following the instructions > > https://phab.enlightenment.org/w/windows/#windows-64-bits > > I keep failing on the autoconf section with errors like : > > configure: error: cannot find install-sh, install.sh, or shtool in "." > "./.." ". > /../.." > make: *** [builddir/efl] Error 1 > > I'm a real newbie to linux toolchains, stucked here for about two weeks... > please help me with some tutorials, I'm really hitting the wall, thanks. > -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
Hi,
> that's why I explicitly removed Edje. Edje pulls too much, and will not
aggregate that much value for the BIOS case (show menu and similar). Of
course it would be nice to have a complete environment with Elementary and
all, > but I don't think it's doable without LOTS of effort, so stick with
Evas first -- particularly pre-Eina Evas.
Maybe I misunderstood about Edje, I thought that was some kind of C like
meta-language layer to seperate UI and code. I'll try to use pre-Eina Evas
though I still couldn't get my Win7 + MinGW right (lots of autotool error)
>If you need to strip the libraries, I'd recommend to remove the following
chunks from Evas:
> - Gradients: it was removed in current Evas, but the pre-Eina still
contained it with lots of useless code;
> - Textblock: if you don't need text markup or multi-line text, you can
remove this and lots of code.
I'l need Textblock for further usage.
> And of course choose the minimum set of engines and options, I'm not sure
the bootloader can use MMX/SSE, then you can compile out those with
./configure flags.
Yes, we have SSE2, which is for security check, grab them libs to use will
be okay.
In UEFI environment we have events and notify, basic Bit blit function to
access raw framebuffer, timers..etc. Not much like the OS but will do some
good.
> NOTE: which hardware are you using this? It seems like a nice hobby
project I'd help on weekends, but I'd need to have a way to test :-)
I use coreboot or UDK2010 (
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UDK2010) ,
the later has some NT32 simulation, which can use as a basic test on host
machines.
But if you are talking about real platform, I almost have everything
because I work in a vendor.
Not familiar to all of this (toolchain, environment and I don't know how to
find E17's writing guide) I have to apologize :( , so t is hard for me to
catch up all the information. But my target is to port a open-sourced UI
lib for BIOS to use, not only in setup menus, but also some UEFI shell
applications, it will magically reduce a lot of working hour, for BIOS /
Driver developers to work only on the function, not to take care the
unawareness of the UI.
On Tue, Apr 30, 2013 at 8:31 PM, Gustavo Sverzut Barbieri <
barbi...@profusion.mobi> wrote:
> Hi,
>
>
> On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler wrote:
>
>> On Tue, 30 Apr 2013 18:03:21 +0800 hYde said:
>>
>> > Since my BIOS has only about 8MB of space, I take Evas + Edje.
>>
>> you'll need ecore, eet and eina too then. (well some of ecore).
>
>
> that's why I explicitly removed Edje. Edje pulls too much, and will not
> aggregate that much value for the BIOS case (show menu and similar). Of
> course it would be nice to have a complete environment with Elementary and
> all, but I don't think it's doable without LOTS of effort, so stick with
> Evas first -- particularly pre-Eina Evas.
>
>
>
>
>
>> > May I ask what is pre-merge?
>>
>> efl 1.7.x ... from efl 1.8 we have a single build tree and we have upped
>> our
>> dependencies. 1.8 is not out yet.. but release is scheduled for end of
>> may.
>
>
> Yes, but I'd strongly encourage to find out the Evas version before Eina
> was introduced. Then you don't need Eina, just Evas types that were built
> in (saves a lib to care and some Kb in the final image).
>
> With Evas all you need is to create an engine similar to "FB", give Evas
> the framebuffer (pixels) to paint and that's it. If you can configure your
> FB, then it should be pretty simple to get it running. You can copy
> Expedite's model, that is basically a loop:
>while (1) {
> event = get_event();
> if (event) process_event(event);
> evas_render_updates(evas);
>}
>
> from process_event() you can arrange your objects as you wish (create,
> move, resize...), evas_render_updates() will take care to draw them to
> output. Eventually you'd have to ask the FB to update itself, depends on
> your setup.
>
> If you need to strip the libraries, I'd recommend to remove the following
> chunks from Evas:
>- Gradients: it was removed in current Evas, but the pre-Eina still
> contained it with lots of useless code;
>- Textblock: if you don't need text markup or multi-line text, you can
> remove this and lots of code.
>
> And of course choose the minimum set of engines and options, I'm not sure
> the bootloader can use MMX/SSE, then you can compile out those with
> ./configure flags.
>
>
> NOTE: which hardware are you using this? It seems like a nice hobby
> project I'd help on weekends, but I'd need to have a wa
Re: [e-users] Really don't know how to start with
Hi, I've read and followed every page which described how to build enlightenment using MinGW + Windows, MinGW / AutoConf / Pkg-config are all up-and-ready but it still refuses to work, still finding the answer why :( I will listen to you, start it all over just stick to evas, and make it work, second target is to port to the same toolchain where the BIOS codebase is using. Thanks. On Tue, Apr 30, 2013 at 10:37 PM, Gustavo Sverzut Barbieri < barbi...@profusion.mobi> wrote: > Hi Hyde, thanks for clarifying, comments below: > > > On Tue, Apr 30, 2013 at 9:48 AM, hYde wrote: > >> Hi, >> >> > that's why I explicitly removed Edje. Edje pulls too much, and will not >> aggregate that much value for the BIOS case (show menu and similar). Of >> course it would be nice to have a complete environment with Elementary and >> all, > but I don't think it's doable without LOTS of effort, so stick with >> Evas first -- particularly pre-Eina Evas. >> >> Maybe I misunderstood about Edje, I thought that was some kind of C like >> meta-language layer to seperate UI and code. >> > > Indeed it is, and would be awesome if you could use it. However, being > higher level, it depend on lots of other EFL, as Raster named Ecore (main > loop, timers...), Evas (canvas), Eina (data types), Eet (binary file chunk > reading lib, similar to "zip"). Of course you can port them, as was done > for PSL1GHT (PS3 native engine), but it's more work. Maybe you can try this > as a second step/milestone. > > > >> I'll try to use pre-Eina Evas though I still couldn't get my Win7 + MinGW >> right (lots of autotool error) >> > > Did you look into Vincent's wiki page: > https://trac.enlightenment.org/e/wiki/EFLWindowsXP > > He was the last one to care about such setup, and I basically removed most > of the support in the current merged tree (the EFL git repo) as we could > not get too broad interest from developers to guarantee it would work. > Before some guys were doing some work to get it running now and then, it > was not constant. > > > >If you need to strip the libraries, I'd recommend to remove the following >> chunks from Evas: >> > - Gradients: it was removed in current Evas, but the pre-Eina still >> contained it with lots of useless code; >> > - Textblock: if you don't need text markup or multi-line text, you >> can remove this and lots of code. >> >> I'l need Textblock for further usage. >> > > Ok. Just note that using Textblock from plain Evas is a PITA, I'd > recommend getting to it via Edje, but then you need the other libraries as > said before. > > > > And of course choose the minimum set of engines and options, I'm not >> sure the bootloader can use MMX/SSE, then you can compile out those with >> ./configure flags. >> Yes, we have SSE2, which is for security check, grab them libs to use >> will be okay. >> >> In UEFI environment we have events and notify, basic Bit blit function >> to access raw framebuffer, timers..etc. Not much like the OS but will do >> some good. >> > > That's basically what we need. You don't need to port everything, just > what you need to make it work. For instance timers and framebuffer access > should be enough, as well as file (fopen) if you need Edje/Eet. Edje may > use Eio that in turn uses inotify on Linux, but you can leave that as empty > stubs or just do not compile. Nowadays Evas also is starting to depend on > Threads, thus it's good to plan such feature in the future. > > > >> > NOTE: which hardware are you using this? It seems like a nice hobby >> project I'd help on weekends, but I'd need to have a way to test :-) >> I use coreboot or UDK2010 ( >> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UDK2010) >> , the later has some NT32 simulation, which can use as a basic test on host >> machines. >> But if you are talking about real platform, I almost have everything >> because I work in a vendor. >> > > Ah, vendor :-D > > > > >> Not familiar to all of this (toolchain, environment and I don't know how >> to find E17's writing guide) I have to apologize :( , so t is hard for me >> to catch up all the information. But my target is to port a open-sourced UI >> lib for BIOS to use, not only in setup menus, but also some UEFI shell >> applications, it will magically reduce a lot of working hour, for BIOS / >> Driver developers to work only on the function, not to take care the >> unawareness of the UI. >> >
Re: [e-users] Really don't know how to start with
wow... Looks like I need to dig in more to study more stuff :(
Is it possible to reduce code size to about 400~700KB after all this?
On Wed, May 1, 2013 at 5:56 PM, Carsten Haitzler wrote:
> On Tue, 30 Apr 2013 09:31:43 -0300 Gustavo Sverzut Barbieri
> said:
>
> > Hi,
> >
> >
> > On Tue, Apr 30, 2013 at 8:57 AM, Carsten Haitzler >wrote:
> >
> > > On Tue, 30 Apr 2013 18:03:21 +0800 hYde said:
> > >
> > > > Since my BIOS has only about 8MB of space, I take Evas + Edje.
> > >
> > > you'll need ecore, eet and eina too then. (well some of ecore).
> >
> >
> > that's why I explicitly removed Edje. Edje pulls too much, and will not
> > aggregate that much value for the BIOS case (show menu and similar). Of
> > course it would be nice to have a complete environment with Elementary
> and
> > all, but I don't think it's doable without LOTS of effort, so stick with
> > Evas first -- particularly pre-Eina Evas.
>
> well you still need eina anyway. so edje adds eet and ecore (ecore,
> ecore-imf,
> ecore-file, ecore-evas, ecore-input, ecore-evas). these ecores are fairly
> small, and ecore-evas pulls in ecore-con and ecore-ipc.
>
> there likely will be the need for ecore anyway for a mainloop etc. so i'd
> guess
> it doesnt end up too bad, and relying on eet as a way of nicely
> encapsulating
> data into a single file will be helpful. lossy compression for images with
> alpha (that jeg doesnt do and png doesnt do) will save you space too if
> you use
> such image data much. so in the end i am not sure it will be too bad.
> elementary thought makes things a whole new level.
>
> > > > May I ask what is pre-merge?
> > >
> > > efl 1.7.x ... from efl 1.8 we have a single build tree and we have
> upped
> > > our
> > > dependencies. 1.8 is not out yet.. but release is scheduled for end of
> may.
> >
> >
> > Yes, but I'd strongly encourage to find out the Evas version before Eina
> > was introduced. Then you don't need Eina, just Evas types that were built
> > in (saves a lib to care and some Kb in the final image).
> >
> > With Evas all you need is to create an engine similar to "FB", give Evas
> > the framebuffer (pixels) to paint and that's it. If you can configure
> your
> > FB, then it should be pretty simple to get it running. You can copy
> > Expedite's model, that is basically a loop:
> >while (1) {
> > event = get_event();
> > if (event) process_event(event);
> > evas_render_updates(evas);
> >}
> >
> > from process_event() you can arrange your objects as you wish (create,
> > move, resize...), evas_render_updates() will take care to draw them to
> > output. Eventually you'd have to ask the FB to update itself, depends on
> > your setup.
> >
> > If you need to strip the libraries, I'd recommend to remove the following
> > chunks from Evas:
> >- Gradients: it was removed in current Evas, but the pre-Eina still
> > contained it with lots of useless code;
> >- Textblock: if you don't need text markup or multi-line text, you can
> > remove this and lots of code.
> >
> > And of course choose the minimum set of engines and options, I'm not sure
> > the bootloader can use MMX/SSE, then you can compile out those with
> > ./configure flags.
> >
> >
> > NOTE: which hardware are you using this? It seems like a nice hobby
> project
> > I'd help on weekends, but I'd need to have a way to test :-)
> >
> >
> > --
> > Gustavo Sverzut Barbieri
> > http://profusion.mobi embedded systems
> > --
> > MSN: barbi...@gmail.com
> > Skype: gsbarbieri
> > Mobile: +55 (19) 9225-2202
> >
> --
> > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> > Get 100% visibility into your production application - at no cost.
> > Code-level diagnostics for performance bottlenecks with <2% overhead
> > Download for free and get started troubleshooting in minutes.
> > http://p.sf.net/sfu/appdyn_d2d_ap1
> > ___
> > enlightenment-users mailing list
> > enlightenment-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-users
> >
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> The Rasterman (Carsten Haitzler)ras...@rasterman.com
>
>
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Really don't know how to start with
Hi: After your detailed explanation, I guess Enlightenment is just what I need. In BIOS environment we have jpg, bmp and png decoder lib already, and picture format we use is just these, so I think I could strip these out. We only need one font, and I've developed a freetype font library, so this one I think is good to go already. In our file system we use LZMA to do the compressing, size doesn't matter when we deploy the lib into memory, so I meant code size is when the lib is in the ROM part. In fact as long as the "self awareness" feature of this UI system doesn't go away after size reducing, it is always worth porting on a BIOS environment, no matter how hard the process goes IMO. Some modern day computers doesn't limited its code size, some already has their BIOS in about 20~200MB flash memory, but 8MB is main stream, I will still sticking to this particular size as a base. When I completed porting, is it okay to do the feedback the files and configs to you? Sticking as a branch of the officials might be good and will get most users have their BIOS decorated. Hope I don't get many issue in office so I could get this work as soon as possible, thank you all. On Thu, May 2, 2013 at 12:00 AM, Carsten Haitzler wrote: > On Wed, 1 May 2013 22:59:43 +0800 hYde said: > > > wow... Looks like I need to dig in more to study more stuff :( > > > > Is it possible to reduce code size to about 400~700KB after all this? > > compressed or uncompressed? evas minus all dependencies and zero modules in > current dev is 1.4m once stripped. its 570k when compressed (so assuming > cramfs > or so then its in your size range), but thats just evas. remember this is > also > with all features on/built in and -O2 with optimization. -Os may do better. > > so evas+eina alone come out at 744kb compressed (again assuming cramfs) > (1.8m > uncompressed). this happens to include buffer engine, a whole bunch of > image > format loaders and more. chances are u can shave off maybe 100-200k by > configuring off things (maybe 100-200k compressed savings). problem is at > least > with current dev (and 1.8) you need to modify configure.ac - we dont have > a > "bios" profile currently. :) > > now if i go disable a bunch of loaders in configure.ac specifically and > use > -Os... and i compress things down.. including eet suport for loaders, jpeg > and > png loader, freetype support no fontconfig), frameubuffer enigne (and > buffer > engine) with small dither array, with eina, eet, evas, and eo... > uncompressed > its 1.6m, compressed 636kb. thats enough stuff there to do display, build > a ui > yourself (place text, images, rects etc.), handle input when fed in from > code > (and route to the right target) load png's and jpgs (assuming u provide > libpng > and libjpeg), render ttf text with anti-aliasing, handle all common/sane > bit > depths (from monochrome up to 24bpp), lots of other fun rendering stuff > (smooth > interpolated scaling), scene graph, text layout and formatting with markup > and > unicode (no RTL support though), and being able to pack data resources into > single eet files for access via key values. you will need in addition > libc/libm/libdl/libpthread, zlib (png needs this anyway), freetype. thats > actually about it. you dont need much more. > > so we can get down to about 640kb plus some external deps. remove png and > jpeg > loader.. if u want to rely on eet entirely and u can save maybe 20k > compressed. > i am sure we could do there things to trim more, but not a hell of a lot. > so is > 640k compressed (out of 8mb) worth using for a pretty complete > display/rendering subsystem including high level text formatting, image > decoding rendering, event routing etc? if i include the deps (freetype, > libjpeg > and libpng - i am skipping zlib, libc etc. as i assume these will be there > no > matter what you use for display), your entire footprint (compressed) is > 1.1M > for everything you need to display. input is still "your problem". :) as it > creating widgets and doing layout. you dont need full blown widgets for a > bios > i imagine... i'd say 1.1m of 8mb is a perfectly adequate footprint. you can > probably get the rest (kernel, libc base etc) down to about 3m, so as such > u'll > probably have about 4.. maybe 5m for the core os and what not. that leaves > u > with 3m for the bios "app" and data files (jpg's, png's etc.). am i far > off the > mark here? > > btw your project is rather fascinating. :) > > > On Wed, May 1, 2013 at 5:56 PM, Carsten Haitzler >wrote: > > > > > On Tue, 30 Apr 2013 09:31:43 -0300 Gustavo Sverzut Barbieri > > > said:
Re: [e-users] Really don't know how to start with
Hi, Digged into configure.ac I found out I could just flip the switches on / off to customized my porting, but somehow still rough, have to fine tune it in c code On Fri, May 3, 2013 at 1:01 AM, Gustavo Sverzut Barbieri < barbi...@profusion.mobi> wrote: > On Wed, May 1, 2013 at 8:30 PM, Carsten Haitzler wrote: > >> On Thu, 2 May 2013 01:35:47 +0800 hYde said: >> >> > Hi: >> > >> > After your detailed explanation, I guess Enlightenment is just what I >> need. >> > In BIOS environment we have jpg, bmp and png decoder lib already, and >> > picture format we use is just these, so I think I could strip these >> out. We >> > only need one font, and I've developed a freetype font library, so this >> one >> > I think is good to go already. >> > >> > In our file system we use LZMA to do the compressing, size doesn't >> matter >> > when we deploy the lib into memory, so I meant code size is when the >> lib is >> > in the ROM part. In fact as long as the "self awareness" feature of >> this UI >> > system doesn't go away after size reducing, it is always worth porting >> on a >> > BIOS environment, no matter how hard the process goes IMO. Some modern >> day >> > computers doesn't limited its code size, some already has their BIOS in >> > about 20~200MB flash memory, but 8MB is main stream, I will still >> sticking >> > to this particular size as a base. >> > >> > When I completed porting, is it okay to do the feedback the files and >> > configs to you? Sticking as a branch of the officials might be good and >> > will get most users have their BIOS decorated. >> >> actually i don't think we want a branch. we're happy to work with you and >> make >> what you need a profile. right now basically we have a full "bloated" >> profile. >> you want something much more stripped down. you MAY also want to use >> ecore, >> ecore_fb and ecore_evas too to save dealing with mainloops, the fb device >> handling, input (kbd/mouse etc.) (well this is linux kernel fbcon etc.) - >> but >> this will add more to what i quoted above, but won't double it. another >> few >> hundred kb, but now your mainloop and input infra is done too. if you >> don't >> need png then of course that saves a little bit too (and eet itself >> handles >> lossless images with alpha as well as lossy, tho eet does still need zlib >> and >> libjpeg). >> > > it's not a profile, similar to PSL1GHT it's a new platform. Platforms can > selectively enable/disable stuff, as done already. > > > > > i think the best thing you can do is go through some iterating of modifying >> configure.ac and turning off what you don't need and making it a >> profile, then >> feeding that back to us and so on - we can advise you on the next step >> etc. and >> pretty much end up with a lean result and it'll then become probably a few >> simple configure options and then some post-install script that maybe >> strips >> out a few extra build outputs like .la files, includes and other things >> you >> wont need at runtime. > > > yes, except ignore it as a profile and make it a platform. EFI != > WindowsXP or other stuff compile from mingw. > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
