I assume you chopped down the boot sequence to load the GUI as quickly as possible. Then after the GUI has loaded, you start daemons like networking and the video input. The least important drivers/daemons are loaded later on.
"QT"? You only remind me of people who talk about running "ID"'s Doom 3 on "MAC" OS X. Understand when something is a word versus initials or acronym. Refer to Qt's own devs regarding this - it's a word, cute, not cue tee.
Removing all the unused unnecessary components and investigating where all the CPU cycles are used. The elinux.org website has a good few starting points.
How can you claim a 98% reduction on an application you've written!? Is this from the standard out of the box devkit sdk with everything enabled to demonstrate the features of the soc? Not quite a real world product scenario in that case.
I bet that you couldn't take an off the shelf product that has the source available and reduce it by 50%! Something that you can get from a highstreet store not digikey or sparkfun.
@jaycrossroads Thanks for the interesting and valid point you raise.
The reason we are able to consistently and greatly reduce boot time is by specialising the software stack to the precise needs of the application. For this reason if an application were to demonstrate every single feature of a SOC - then achieving such a small boot time would be more challenging and taking an alternative approach to boot time optimisation may be more cost-effective.
@jaycrossroads By taking the approach of specialising the software stack we are consistently able reduce boot time in customers' real world devices by more than 50%. This works because it's very rare that a customer's real world device uses all the features of their SOC (at least on application start-up). In any case boot time reductions are made not only by removing un-requried functionality - but also by optimising required functionality - and deferring function not required at start up.
I assume you chopped down the boot sequence to load the GUI as quickly as possible. Then after the GUI has loaded, you start daemons like networking and the video input. The least important drivers/daemons are loaded later on.
lordtaw 2 months ago
E mais uma vez LINUX sai na frente! \0_
claytonlobo 10 months ago
wow pcs suck look at that terrible penguin graphics
get a mac its better
dingumfCallofDuty 1 year ago
@dingumfCallofDuty -50/10 you are not even trying.
JerichoKru 1 year ago
my Atari ST also boot in 1 sec! :D
zarjesve2 1 year ago
"QT"? You only remind me of people who talk about running "ID"'s Doom 3 on "MAC" OS X. Understand when something is a word versus initials or acronym. Refer to Qt's own devs regarding this - it's a word, cute, not cue tee.
nawcom 1 year ago
Removing all the unused unnecessary components and investigating where all the CPU cycles are used. The elinux.org website has a good few starting points.
J
jaycrossroads 1 year ago
@jaycrossroads This demo is based on the pre-provided BSP for this board - the QT application we used was similar in it's boot time characteristcs.
MPCData 1 year ago 3
Plenty of smoke and mirrors here!
How can you claim a 98% reduction on an application you've written!? Is this from the standard out of the box devkit sdk with everything enabled to demonstrate the features of the soc? Not quite a real world product scenario in that case.
I bet that you couldn't take an off the shelf product that has the source available and reduce it by 50%! Something that you can get from a highstreet store not digikey or sparkfun.
This isn't rocket science! it's all about
jaycrossroads 1 year ago
@jaycrossroads Thanks for the interesting and valid point you raise.
The reason we are able to consistently and greatly reduce boot time is by specialising the software stack to the precise needs of the application. For this reason if an application were to demonstrate every single feature of a SOC - then achieving such a small boot time would be more challenging and taking an alternative approach to boot time optimisation may be more cost-effective.
MPCData 1 year ago 7
@jaycrossroads By taking the approach of specialising the software stack we are consistently able reduce boot time in customers' real world devices by more than 50%. This works because it's very rare that a customer's real world device uses all the features of their SOC (at least on application start-up). In any case boot time reductions are made not only by removing un-requried functionality - but also by optimising required functionality - and deferring function not required at start up.
MPCData 1 year ago 4