On Thu, Nov 3, 2016 at 4:17 PM, William Hermans <[email protected]> wrote: > > > On Thu, Nov 3, 2016 at 9:19 AM, Gary Thomas <[email protected]> wrote: >> >> On 2016-11-03 15:22, Robert Nelson wrote: >>> >>> On Thu, Nov 3, 2016 at 9:18 AM, Gary Thomas <[email protected]> wrote: >>>> >>>> On 2016-11-03 15:11, Robert Nelson wrote: >>>>>> >>>>>> >>>>>> Thanks, I'll investigate these changes. >>>>>> >>>>>> Based on the comment "first valid device probed", is there any way to >>>>>> force the eMMC to be the first valid device (I might be able to live >>>>>> with >>>>>> the fact that U-Boot sees the eMMC as dev 1 but Linux as dev 0 if it >>>>>> was >>>>>> always consistent). >>>>>> >>>>>> Again, thanks for any ideas/pointers >>>>> >>>>> >>>>> >>>>> Going forward, it will be consistent.. >>>>> >>>>> microSD = ti mmc1 port -> mmc0 kernel >>>>> eMMC = ti mmc2 port -> mmc1 kernel >>>> >>>> >>>> >>>> What does "going forward" mean? I'm not seeing this, using >>>> the latest Debian+U-Boot >>>> >>>> What you've outlined above would be ideal, I'm just curious >>>> how to get it. >>> >>> >>> Well let's see: >>> >>> I merged it into our tree on Jul 19, 2016, at tag: 4.4.15-ti-r37 >>> >>> If your running something older then just: >>> >>> cd /opt/scripts/tools/ ; git pull ; sudo ./update_kernel.sh >> >> >> That's fine and good, but I can't test it running eMMC only (no SD) >> as the image can't be flashed to my (revA) board that only >> has 2GB eMMC, so I can't really test anything using these >> tools :-( >> > > Unless I'm mistaken. That script only pulls in the latest kernel + initrd + > modules, etc. Needed to boot the new kernel. Typically we're talking . . . > > william@beaglebone:~$ du -h /boot/*`uname -r` > 3.2M /boot/System.map-4.4.14-ti-r34 > 144K /boot/config-4.4.14-ti-r34 > 4.5M /boot/initrd.img-4.4.14-ti-r34 > 7.5M /boot/vmlinuz-4.4.14-ti-r34 > > william@beaglebone:~$ du -h /boot/dtbs/*`uname -r` > 13M /boot/dtbs/4.4.14-ti-r34 > > william@beaglebone:~$ du -h /lib/modules/`uname -r` > . . . > 66M /lib/modules/4.4.14-ti-r34 > > Roughly 100M, plus you'll need around another 60-70M for the package as it > downloads / installs. After which it could be purged. Plus maybe a little > extra I'm forgetting. > > Anyway, if that script wont work you can always run > > $ apt-cache search linux-image |grep <whatever version you want> > > Another thing to keep in mind. Is that lately ( as in the last several > months atleast ) the kernel modules have been built with debugging symbols > built in . . . which increases their size drastically. Or so I've been told. > Personally, I think this is something that needs being done outside of > released images . . . but I'm not the one who has the honor of building the > kernel images weekly . . . thank god ;)
CONFIG_DEBUG_INFO is now disabled... The dbg symbols, while smaller then they use to be, still just ended up taking up too much server space. ;) Regards, -- 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/CAOCHtYi0wRVo8hrWm4%3DTmoFwPZv34UDV433gWbDyrLpCDGXaKQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
