By the way, the kernel I failed with was: linux-image-4.4.43-bone-rt-r16 On Wed, Jan 18, 2017 at 9:32 AM, William Hermans <yyrk...@gmail.com> wrote:
> So, I've tested this a few times over the last . . .<whatever it's been > since announcement >, and I have found that loading a single overlay seems > to work really good. Attempting multiple overlays however, seems to be an > exercise in frustration. e.g. It's not ready. It's possible that I got > something wrong, but I do not usually do that more than once. I've tried > multiple times. > > So my recommendation is, if you're an embedded Linux noob, or a beginner > to this platforms boot process. Steer clear. If you're reasonably > experienced in both of these areas, and don't mind testing - Have fun. But > I would definitely strongly advise to not attempt this on a production > system. > > Basically what happens is uboot complains that the cmdline kernel > parameter does not contain a valid flattened device tree overlay path. Why > exactly, I'm not sure. I did see uboot "mention" that it can not find a > valid partition for partitions 1-6 . . . which I think may be standard > uboot debug output. First, it checked the path for the UUID, then attempted > the blk device. Failing ( or flailing ). However, this works perfectly fine > when using: > > ##Example v4.1.x >> #cape_disable=bone_capemgr.disable_partno= >> cape_enable=bone_capemgr.enable_partno=controller,BB-ADC,BB-W1-P8.26 >> > > After making sure the overlays exist in /lib/firmware/, and then running: > > root@beaglebone:~# cd /opt/scripts/tools/developers/ >> root@beaglebone:/opt/scripts/tools/developers# ./update_initrd.sh >> root@beaglebone:/opt/scripts/tools/developers# reboot >> > > One should also keep in mind that if you update to a newer kernel before > this process. Make sure you reboot into your new kernel first. Otherwise > your board *WILL* boot, but the boot process will stop inside the > initramfs. I fell into this trap myself, and basically what happens. You > will end up updating the initramfs you just replaced, while leaving the > replacement initramfs without a clue as to where to go next. Once the > initramfs loads that is. > > Anyway, this is a potentially really cool, and good feature. I look > forward to this working flawlessly in the future. However, at this point in > time, I have to give testing a pass. As I have other priorities that must > come first - currently. > -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORoGCkgSi_6rdESMt%3DPsu59pp39GzE%3DQDLHfruntV0QHNA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
