> A quick grabserial log:
>
> [0.000001 0.000001]
> [0.000084 0.000083] U-Boot SPL 2019.04-00002-gbb4af0f50f (Jul 08 2019 - 
> 11:44:39 -0500)
> [0.048198 0.048114] Trying to boot from MMC1
> [0.128443 0.080245] Loading Environment from EXT4... ** File not found 
> /boot/uboot.env **
> [0.176759 0.048316]
> [0.176803 0.000044] ** Unable to read "/boot/uboot.env" from mmc0:1 **
> [0.257320 0.080517]
> [0.257422 0.000102]
> [0.257473 0.000051] U-Boot 2019.04-00002-gbb4af0f50f (Jul 08 2019 - 11:44:39 
> -0500), Build: jenkins-github_Bootloader-Builder-128
> [0.261285 0.003812]
> [0.261331 0.000046] CPU  : AM335X-GP rev 2.1
> [0.262184 0.000853] I2C:   ready
> [0.305677 0.043493] DRAM:  512 MiB
> [0.353349 0.047672] No match for driver 'omap_hsmmc'
> [0.354567 0.001218] No match for driver 'omap_hsmmc'
> [0.392303 0.037736] Some drivers were not found
> [0.393526 0.001223] Reset Source: Global external warm reset has occurred.
> [0.396006 0.002480] Reset Source: Power-on reset has occurred.
> [0.398008 0.002002] RTC 32KCLK Source: Internal.
> [0.399596 0.001588] MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> [0.401448 0.001852] Loading Environment from EXT4... ** File not found 
> /boot/uboot.env **
> [0.500941 0.099493]
> [0.500992 0.000051] ** Unable to read "/boot/uboot.env" from mmc0:1 **
> [0.574400 0.073408] Model: BeagleBoard.org PocketBeagle
> [0.575353 0.000953] <ethaddr> not set. Validating first E-fuse MAC
> [0.576464 0.001111] Net:   usb_ether
> [0.576935 0.000471] Press SPACE to abort autoboot in 2 seconds
> [2.559828 1.982893] board_name=[A335PBGL] ...
>
>
> Only a 1/2s of waste up to here. The 2s delay is intentional. I'm tempted to 
> set the boot environment and BOOTDELAY to clear this one.

I believe this is a waste too, i'd like to nuke the whole 2s delay,
the space bar can still abort it, but most users never buy a serial
cable...


>
> [2.656112 0.096284] switch to partitions #0, OK
> [2.657331 0.001219] mmc0 is current device
> [2.736225 0.078894] SD/MMC found on device 0
> [2.762987 0.026762] gpio: pin 56 (gpio 56) value is 0
> [2.764810 0.001823] gpio: pin 55 (gpio 55) value is 0
> [2.766536 0.001726] gpio: pin 54 (gpio 54) value is 0
> [2.768192 0.001656] gpio: pin 53 (gpio 53) value is 1
> [2.770000 0.001808] starting USB...
> [2.770900 0.000900] USB0:   Port not available.
> [3.755765 0.984865] gpio: pin 54 (gpio 54) value is 1
>
>
> hmmm.... that's quite a delay. This also seems like a good candidate for 
> elimination with configuring the boot environment.

I nuked the USB0 path yesterday, as the resolve isn't going to ship...


>
> [3.771881 0.016116] Checking for: /boot/uEnv.txt ...
> [3.877247 0.105366] switch to partitions #0, OK
> [3.878375 0.001128] mmc0 is current device
> [3.879302 0.000927] gpio: pin 56 (gpio 56) value is 0
> [3.880383 0.001081] gpio: pin 55 (gpio 55) value is 0
> [3.881447 0.001064] gpio: pin 54 (gpio 54) value is 0
> [3.882650 0.001203] gpio: pin 53 (gpio 53) value is 1
> [3.957024 0.074374] switch to partitions #0, OK
> [3.958922 0.001898] mmc0 is current device
> [4.036965 0.078043] gpio: pin 54 (gpio 54) value is 1
> [4.117177 0.080212] Checking for: /uEnv.txt ...
> [4.149090 0.031913] Checking for: /boot.scr ...
> [4.165031 0.015941] Checking for: /boot/boot.scr ...
> [4.180923 0.015892] Checking for: /boot/uEnv.txt ...
> [4.213085 0.032162] gpio: pin 55 (gpio 55) value is 1
> [4.245069 0.031984] 2340 bytes read in 34 ms (66.4 KiB/s)
> [4.246042 0.000973] Loaded environment from /boot/uEnv.txt
> [4.278298 0.032256] debug: [dtb=am335x-pocketbeagle.dtb] ...
> [4.280809 0.002511] Using: dtb=am335x-pocketbeagle.dtb ...
> [4.283421 0.002612] Checking if uname_r is set in /boot/uEnv.txt...
> [4.286133 0.002712] gpio: pin 56 (gpio 56) value is 1
> [4.288118 0.001985] Running uname_boot ...
> [4.293022 0.004904] loading /boot/vmlinuz-4.14.108-ti-r113 ...
> [4.949998 0.656976] 9929216 bytes read in 657 ms (14.4 MiB/s)
>
>
> Pretty big kernel, but not too bad to spend 1/2s here. Almost 10M. A trimmed 
> kernel would still be about 2M. A possible place to optimize, but one with 
> big trade-offs.
>
> [4.966652 0.016654] debug: [enable_uboot_overlays=] ...
> [5.002822 0.036170] loading 
> /boot/dtbs/4.14.108-ti-r113/am335x-pocketbeagle.dtb ...
> [5.064918 0.062096] 124423 bytes read in 54 ms (2.2 MiB/s)
> [5.066676 0.001758] uboot_overlays: add [enable_uboot_overlays=1] to 
> /boot/uEnv.txt to enable...
> [5.080701 0.014025] loading /boot/initrd.img-4.14.108-ti-r113 ...
> [5.455137 0.374436] 4696515 bytes read in 326 ms (13.7 MiB/s)
>
>
> If we aren't really running from this initrd, why spend the time to load it?

remove the "/boot/initrd.img-4.14.108-ti-r113" file and u-boot will
skip loading it..

>
> [5.457428 0.002291] debug: [console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro 
> rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 
> rng_core.default_quality=100 quiet modules-load=g_serial] ...
> [5.464145 0.006717] debug: [bootz 0x82000000 0x88080000:47a9c3 0x88000000] ...
> [5.466492 0.002347] ## Flattened Device Tree blob at 88000000
> [5.467819 0.001327]    Booting using the fdt blob at 0x88000000
> [5.469190 0.001371]    Loading Ramdisk to 8fb85000, end 8ffff9c3 ... OK
> [5.487277 0.018087]    Loading Device Tree to 8fb63000, end 8fb84606 ... OK
> [5.503357 0.016080]
> [5.503431 0.000074] Starting kernel ...
> [5.504097 0.000666]
> [7.040070 1.535973] [    0.001542] timer_probe: no matching timers found
>
>
> 1.5s to before the kernel starts printing messages? Is this mostly due to 
> decompression? Certainly something to pay attention to here.

So we use LZO, maybe it's time to switch to LZ4:

  │ LZ4 is an LZ77-type compressor with a fixed, byte-oriented
encoding.
                                      │
  │ A preliminary version of LZ4 de/compression tool is available at

                              │
  │ <https://code.google.com/p/lz4/>.

                              │
  │

                              │
  │ Its compression ratio is worse than LZO. The size of the kernel

                              │
  │ is about 8% bigger than LZO. But the decompression speed is

                              │
  │ faster than LZO.


As of Debian Buster, LZ4 is now pretty stable:

https://packages.debian.org/source/buster/lz4

>
> [7.062996 0.022926] [    0.936616] wkup_m3_ipc 44e11324.wkup_m3_ipc: could 
> not get rproc handle
> [7.237535 0.174539] [    1.137073] omap_voltage_late_init: Voltage driver 
> support not added
> [7.260652 0.023117] [    1.144372] PM: Cannot get wkup_m3_ipc handle
> [7.307415 0.046763] [    1.208281] PM: Cannot get wkup_m3_ipc handle
> [7.769046 0.461631] [    1.651529] musb-hdrc musb-hdrc.1: VBUS_ERROR in 
> a_wait_vrise (80, <SessEnd), retry #3, port1 0008010c
>
>
> Hmmm.... would this go away if I had something connected?
>
> [12.556108 4.787062] rootfs: recovering journal
>
>
> Ugh. Now this is serious. Should I have the file system mounted read-only and 
> only have Python scripts switch it to writable as-needed? I cannot expect 
> people will perform consistent graceful shutdowns.
>
> [12.636161 0.080053] rootfs: clean, 83681/230144 files, 589372/920576 blocks
> [18.112197 5.476036] You are in rescue mode. After logging in, type 
> "journalctl -xb" Give root password for maintenance
>
>
> Hmmm. What am I missing about what is going on here? Is this more file system 
> work or something else in the system. I probably need to overlay a systemd 
> report here...
>
>
> [18.304912 0.192715] (or press Control-D to continue):
>
> root@beaglebone:~# systemd-analyze
> Startup finished in 7.153s (kernel) + 4.770s (userspace) = 11.924s
> root@beaglebone:~# systemd-analyze blame
>          10.874s dev-mmcblk0p1.device
>           2.791s systemd-udev-trigger.service
>           2.124s keyboard-setup.service
>           1.175s systemd-journald.service
>            704ms systemd-modules-load.service
>            682ms systemd-tmpfiles-setup-dev.service
>            565ms sys-kernel-debug.mount
>            548ms systemd-random-seed.service
>            545ms systemd-timesyncd.service
>            414ms systemd-sysctl.service
>            382ms kmod-static-nodes.service
>            381ms systemd-udevd.service
>            323ms systemd-remount-fs.service
>            255ms dev-mqueue.mount
>            241ms sys-kernel-config.mount
>            238ms systemd-update-utmp.service
>            227ms sys-fs-fuse-connections.mount
>            223ms systemd-tmpfiles-setup.service
>            207ms systemd-journal-flush.service
>            174ms systemd-update-utmp-runlevel.service
>
>
>
> OK then. Booting from microSD on an unclean filesystem is rough. Thoughts?
>
> --
> 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/9b7970d5-b062-4660-bf8f-97a5e852ffc4%40googlegroups.com.



-- 
Robert Nelson
https://rcn-ee.com/

-- 
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/CAOCHtYjHJaLXdEUn1Bu8hOGQ%2BTO-HWMeJt38yYs6yGoDoTuoCw%40mail.gmail.com.

Reply via email to