On 1/25/15, 1:50 PM, "Robert P. J. Day" <[email protected]> wrote:
>On Sun, 25 Jan 2015, John Syn wrote: > >> >> On 1/25/15, 1:33 PM, "Robert P. J. Day" <[email protected]> wrote: >> >> > >> > still on the subject of filling out my wiki page here: >> > >> >http://www.crashcourse.ca/wiki/index.php/RCN_eewiki_BBB_page >> > >> >using the theme of minimal steps, each step being testable before >> >going on to the next step, first, if anyone wants to comment on what's >> >already there and suggest corrections, bring it on. >> > >> > and i was pondering what would be the very next "step" in the >> >process and realized, even before getting into building and letting >> >u-boot boot the kernel, the next teeny step would be to format the >> >rest of the card, then install *nothing* but /boot/uEnv.txt in the new >> >ext4 filesystem where u-boot would find it. >> > >> > does that make sense? it's the smallest unit of progress i can think >> >of that would still have an effect on the boot process. *then* the >> >kernel and the dtb ... >> Hi Robert, >> >> I understand what you are attempting to do, but won¹t it be more >> helpful if you explained to your students how to interpret the >> console output. For example if there is no MLO, you will see >> ³CCCCCC² printed. If it cannot find a valid u-boot or DTB file. What >> happens when there is no kernel magic number. What happens when >> there is no valid rootfs, etc. Just a thought. > > all good points, but at the moment, i'm just trying to put together >something *very* quick and dirty for this week. and it's not meant to >be read standalone, it's meant to be accompanied by, well, me >standing up at the front walking people through it. > > also, if i try to cover every conceivable detail and contingency, >then it's turning into a book, and that's *exactly* what i'm trying to >avoid. Hi Robert, You may be correct, but here is a way I think that might simplify things. Working backwards from a working system might be a good approach. Start with a working system and update uEnv.txt file to make the console output more verbose, and then after a complete boot, copy that console output. Break the rootfs and then make a copy of that console output. Next, break the kernel and make a copy of that console output. Next, remove the DTB file and record the console output. Next break u-boot and record the console output. Next break MLO. If your students study these console outputs, they will see a pattern and will have a better understanding of what to look for in the future. This seems to work for me, but you are the Prof, so I defer to you if this will help your students. Regards, John > >rday > >-- > >======================================================================== >Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > >Twitter: http://twitter.com/rpjday >LinkedIn: http://ca.linkedin.com/in/rpjday >======================================================================== -- 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]. For more options, visit https://groups.google.com/d/optout.
