A follow up on this. Looking at the uBoot printouts, I thought there was 2 things I could do to speed up the boot time: - Zero the bootdelay (currently set to 2s) - Locate uEnv.txt/boot.scr on the root to save .2s (...), since currently it's looking in 2 different locations
To change bootdelay, I was hoping to just get on the uboot boot prompt, =>setenv bootdelay 0 =>saveenv But unfortunately saveenv is not a command of the version I am running => version U-Boot 2016.01-00001-g4eb802e (Jan 13 2016 - 11:14:31 -0600) arm-linux-gnueabihf-gcc (Linaro GCC 5.2-2015.11) 5.2.1 20151005 GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10 And so I guess I cloned uboot git clone git://git.denx.de/u-boot.git And started to look for bootdelay. Well it turns out there's quite a few entries for bootdelay. Would somebody be kind enough to point me to the place where I need to effectively change the default value? Regards, JS On Fri, Oct 28, 2016 at 8:34 AM, Jean-Sebastien Stoezel < [email protected]> wrote: > > Mark: > > I've finally found quite a few interesting pages and documents and I will > be going over them over the week-end. > To answer your question, I would like to get down to about 5s total boot > time. > > Regards, > JS > > On Thu, Oct 27, 2016 at 3:56 PM, Mark Lazarewicz <[email protected]> > wrote: > >> I used Google beagleboard boot time I'd help but my focus is barebone or >> RTOS embedded systems not linux. From memory I think the biggest reduction >> is obtained from loading linux. Try that search and take a look at the >> results and if still don't see anything useful I'll post links. What kind >> of total boot time are your requirements ? >> >> Sent from Yahoo Mail on Android >> <https://overview.mail.yahoo.com/mobile/?.src=Android> >> >> On Thu, Oct 27, 2016 at 8:41 AM, Jean-Sebastien Stoezel >> <[email protected]> wrote: >> Lazarman: >> >> To answer your question, yes I have used the Google search in the group >> and I did not find something that applied directly to my questions: >> - The information I found on how to disable the timeout where either to >> vague for me to figure out, or did not seem to apply to the configuration >> on my board, >> - I did not find anything related to customizing the bootup, apart from >> enabling/disabling capes manually in uEnv.txt. My question is related to >> forcing states in the bootup scripts rather than automatic detection >> >> Now since you seem to have written a tutorial on how to speed up boot >> time, and since this did not show up in the search results, would it be >> possible for you to link directly to it? This I feel, would be a useful >> piece of information to this thread. >> >> Regards, >> JS >> >> >> On Tuesday, October 25, 2016 at 11:40:50 AM UTC-5, Jean-Sebastien Stoezel >> wrote: >>> >>> Hi: >>> >>> I am running a Beagle Bone with a custom cape and I am looking for ways >>> to reduce its boot time. The cape will always be the same and so I'd like >>> to see what it is I can change to reduce or completely remove custom auto >>> detection scripts. >>> As of now, the board boots in 18s, 8s are spent in the kernel, 10s are >>> spent in user space. >>> >>> I have seen numbers out stating that the kernel can boot in less than >>> 2s. I'd be interested to know how this is possible. I am aware of a timeout >>> being used in the kernel, though I am not sure how to disable this (using >>> 4.1.33-bone-rt-r24). >>> >>> Currently generic-board-startup.service seems to be the service that >>> takes the longest to complete. Looking at what it does, it seems to be >>> invoking am335x_evm.h.sh. I am wondering if I could disable anything >>> related to detecting capes (including trying to read the eeprom). At this >>> time I can see lines 30 to 55 in the scripts being related to eeprom >>> flashing/reading, though I am not sure this is targetting the cape's eeprom. >>> >>> In general, how would I go about disabling auto detection of capes? >>> Would I need to edit these scripts? Or is there a cleaner way to disable >>> features by editing a config file? >>> >>> Regards, >>> JS >>> >>> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/beagleboard/a8ddaef0-61e9-461a-9f69-a02f9b3a0e82%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/a8ddaef0-61e9-461a-9f69-a02f9b3a0e82%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAO72MRv2ZbMHWP1%2BmwaxBnL1Ez_vseJZ_T%3DLjN-0XCuZy8YgtQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
