piCore USB booting for speed

[xenodius]

I've searched the forums and found plenty of examples of tinyCore USB booting but nothing on piCore/raspberry pi's. From what I've read elsewhere it sounds like in the case of the pi, once the bootloader EEPROM is updated appropriately it can boot directly from USB without any SD card at all. Has anyone tried this with piCore? Any reason why it might not work? Just checking for others experiences before I shell out for a zippy SSD. I don't actually have any working USB drives around to test with.

My only interest is to reduce boot time. All told my dashboard app is ~480mb, after using strace and many hours of experimentation to trim every non-essential file it still takes about a full minute to boot and open the app, of which ~45 seconds are spent loading these extensions. I'm already using a UHS-1 microSD (Sandisk Extreme Pro). There are a lot more features I would like to add as I find the time, but these will add hundreds more mbytes and the boot time is already too long. Even if it was not possible to boot piCore directly from a USB SSD drive, I'm sure I could boot piCore from microSD then load extensions from an SSD...

Anyone done this on a pi yet?

[Paul_123]

Yes, it works fine.  But will not speed up the boot process.  In fact it will slow it down, since the kernel has to wait for the usb subsystem to initialize and recognize the usb stick

[xenodius]

Thanks for the heads up! I was worried about that, but hoped that if I'm spending ~45 seconds loading extensions already the gains of using SSD would outpace any of those fixed delays.

[Rich]

Hi xenodius
You could try adding the  syslog  boot code. Then take a look through  /var/log/messages (and messages.0 if it exists)
to see if there are any big gaps in the timestamps. That may provide some more useful information to where the
delays are occurring.

[curaga]

480mb? Yikes, that sounds like one of those monsters that embed node.js or the Chromium engine (Electron, CEF, etc). In that case, switching technologies would provide massive gains.

If your UHS-1 card reads at the faster stated 104 mb/s speed, a SSD won't help - the loading is cpu-bound. There are some ways to hack things for faster loading, depending on the file layout - say there's a read-only dir with several thousand js files, that only one extension adds files to. Instead of having it as-is in the extension, the extension would have just the empty dir, its contents as a separate squashfs archive, and the startup script would mount it. This approach has been used for very large things like libreoffice to speed up boot (in a custom setup).

However, the big gains would not come from tricks like that, but from changing tech and reducing the footprint.

[patrikg]

Have you tried to pack the elf files with upx ?
I haven't tried the upx on the raspberry pi before, if it works??

I think maybe this can be done with all the elf files, to reduce the loading time.

https://upx.github.io/

[xenodius]

Guys, thank you for all your thoughtful replies. I have gone through syslog previously, and found by far the most time is spent on a subset of Qt and all the TC.tcz extensions. I don't think the UHS card actually ever hits speeds that fast on the Pi, but it may very well be CPU-bound anyway-- I'm trying to setup piCore 12 64-bit atm.  UPX sounds even better than squashfs... maybe, I will experiment with that startup script approach when I get 'accessory' extensions ready, to load only after the current boot process I'm trying to improve.

~85% of that whole 480mb is QtCore, QtGui, and QtWidgets libraries, which I am accessing through PyQt for my dashboard and later want to use for Marble navigation as well. I have thought that this is just... HUGE even for a GUI like Qt, the whole Qt library without docs, examples, and many features excluded was still almost 1GB, but I already spent a lot of time building my app and custom widgets with it so I just assumed this was necessary.

I think now this problem is my own fault, what happens when a quarantine-crazy novice keyboard commando commits to teaching himself a whole lot of new stuff and has no idea what he's doing... by chance I encountered some references to Qt build sizes and have learned that apparently, I should be able to build the library in a few percent as much size as I have by using static linking and/or using the -release configure flag to get rid of dev elements.   Should know exactly how much smaller I can make it in a few days... lol. If I can make it that small, it should boot in less than half the time!

[Juanito]

You could take a look at how the qt-5.x extensions are divided up in the x86 repo - perhaps you only need one or two of the smaller extensions?

[xenodius]

That's a good idea, I was able to cut ~2/3rds of the original build size by using strace and filters already-- only need 3 submodules-- but I'll check the repo for tips since I'm about to repeat the process. It was actually by looking at the build log for qt-specific tips when I began to repeat this process on x64, that I noticed the -release flag and realized that was why my last build was so massive.