I have a custom board derived from the DM6467T EVM design. I boot up linux into a default codec engine application, from NAND memory only. It takes between 2 and 2.5 minutes from power on until my application begins running. Please help me figure out how to speed things up!
Analyzing the timing, I find the following major offenders, in order:
- 65 SECONDS -- Loading the codec [into the DSP] seems to take 65 seconds when booting from NAND. I fall asleep waiting for it! When booting with the root fs on NFS, it takes 12 seconds. Why is it so slow? Is the NAND memory really that slow, or is something else going on?
- I'm using NAND01GW3B2AZA6E, which I believe it the same or very similar to the EVM.
- My codec server includes only a single codec, my custom one. The .x64P file is 1,077,342 bytes. I'm not aware of any compiler output listings or maps that I can look at to give more detail about the runtime size of the codec server.
- How can I speed this up?
- Note I'm loading my application via a file in folder rc5.d. I think this means the kernel has gotten to level 5, essentially finished, before it loads the application. Might it work to load the application much earlier, to overlap the codec server load with other kernel boot stuff? It depends on HOW early I can get this to happen. If it's not early enough, so much so as to overlap with other slow kernel things, then it's not worth the effort. HOW EARLY CAN I GET MY APP TO LOAD, SUCH AS AT rc0.d? Note I realize I would need to modify my app to spin off a thread to load the codec server, so the rest of kernel boot could continue, I believe. I would also have to modify the app to NOT open any video I/O yet, using probably a later rc5.d-based signal of some kind. This is all very complicated. Again, how early might I be able to start loading the codec server?
- Or is there an existing codec server preload capability somewhere?
- 26 SECONDS -- Over time, I get an increasing number of warning messages during boot, and these now take 26 seconds. The messages are of the form "Empty flash at 0x0029578c ends at 0x00295800". They follow the kernel log message "drivers/rtc/hctosys.c: unable to open rtc device (rtc0)" and precede the message "VFS: Mounted root (jffs2 filesystem) on device 31:3.". I'm thinking they are part of the jffs2 mounting of the NAND file system.
- What causes these messages to appear? I haven't been doing anything strange, to my knowledge, to mess up the NAND memory. Things work fine later anyway. Note I do have one (unrelated) bad block in NAND, kernel boot log says "Bad eraseblock 820 at 0x000006680000".
- In general, I'm not sure if the empty flash messages are the reason for the slowness. Is it a general file system test occuring before/during the mount? Perhaps it's unwise to try to avoid it. But really, is this check slow regardless, or are the empty blocks slowing it down?
- 11 SECONDS -- It takes 11 seconds from the first to last mention of "udev". I'm thinking I need it. I do get a number of errors. Consider this log snippet:
Please wait: booting...
Starting udev
JFFS2 notice: (988) check_node_data: wrong data CRC in data node at 0x019c57a8:
read 0x835dcde4, calculated 0x6ee6fa4d.
dev: starting version 141
udevd[1001]: inotify_add_watch(3, (null), 10) failed: Bad address
udevd[1001]: inotify_add_watch(3, (null), 10) failed: Bad address
udevd[1001]: inotify_add_watch(3, (null), 10) failed: Bad address
udevd[1001]: inotify_add_watch(3, (null), 10) failed: Bad address
udevd[1001]: inotify_add_watch(3, (null), 10) failed: Bad address
udevd[1001]: inotify_add_watch(3, (null), 10) failed: Bad address
udevd[1001]: inotify_add_watch(3, (null), 10) failed: Bad address
udevd[1001]: inotify_add_watch(3, (null), 10) failed: Bad address
udevd[1001]: inotify_add_watch(3, (null), 10) failed: Bad address
Remounting root file system...
root: mount: mounting rootfs on / failed: No such file or directory- I notice a large number of entries under /dev. Might things speed up if I get rid of a bunch of them, like the slew of tty* devices?
- When I boot from NFS, it takes even longer, 16 seconds. I do still get the "Bad address" errors.
- Note that the 11 second delay is substantially AFTER the last "Bad address" errors and before the "Remounting".