for people teaching embedded linux classes, a suggestion ...

currently working my way through RCN's eewiki beaglebone page here:

https://eewiki.net/display/linuxonarm/BeagleBone+Black

and for others who also teach EL classes, here's something i do that
seems to be a bit different from most presentations (and online pages)
i've seen.

  most presentations seem to like downloading and building
*everything* (MLO, u-boot, kernel, dtb and rootfs) before getting
around to formatting an SD card, copying it all on, then testing.

  when i'm presenting this, i prefer to do the creation and testing in
bite-size pieces to isolate build errors much faster. for instance, i
will get students to do nothing more than download u-boot source,
possibly patch it, cross-compile, then copy MLO and u-boot.img to the
SD card and try to boot that.

  as long as the class has access to the serial port (i'm assuming
that), the only test they'll be making is if u-boot comes up, and they
can stop there and look around. they'll know they can't go any
further, but that's all right -- that at least verifies that their
build and install of u-boot seems to be fine, and if it isn't,
debugging should be easy.

  once that's verified, move on to format the rest of the SD card and
copy, say, just the kernel and dtb file, then try to boot *that*.
again, students will understand there's no rootfs but all they're
testing is if the kernel seems to load and boot. and if it fails, once
again, debugging should be easy.

  finally, add the rootfs. anyway, that's the approach i prefer, and
it seems to work as students like to be able to build *and test*
something fairly quickly, rather than just doing a massive amount of
work, and wondering if it will work in the end.

rday

Thanks for the advice Robert!

I am currently working thru the same page, more or less as a student :slight_smile:
And you suggestions sound excellent. I would be interested to hear you
advice on selecting
Kernel build options, from the menu. Do you think there is such a thing as a
"default" configuration ??

Bill

currently working my way through RCN's eewiki beaglebone page here:

https://eewiki.net/display/linuxonarm/BeagleBone+Black

and for others who also teach EL classes, here's something i do that seems
to be a bit different from most presentations (and online pages) i've seen.

  most presentations seem to like downloading and building
*everything* (MLO, u-boot, kernel, dtb and rootfs) before getting around to
formatting an SD card, copying it all on, then testing.

  when i'm presenting this, i prefer to do the creation and testing in
bite-size pieces to isolate build errors much faster. for instance, i will
get students to do nothing more than download u-boot source, possibly patch
it, cross-compile, then copy MLO and u-boot.img to the SD card and try to
boot that.

  as long as the class has access to the serial port (i'm assuming that),
the only test they'll be making is if u-boot comes up, and they can stop
there and look around. they'll know they can't go any further, but that's
all right -- that at least verifies that their build and install of u-boot
seems to be fine, and if it isn't, debugging should be easy.

  once that's verified, move on to format the rest of the SD card and copy,
say, just the kernel and dtb file, then try to boot *that*.
again, students will understand there's no rootfs but all they're testing is
if the kernel seems to load and boot. and if it fails, once again, debugging
should be easy.

  finally, add the rootfs. anyway, that's the approach i prefer, and it
seems to work as students like to be able to build *and test* something
fairly quickly, rather than just doing a massive amount of work, and
wondering if it will work in the end.

rday

Sounds different from traditional teaching Robert, but also sounds like a good thing to me. Seems like it would help teach critical thinking (troubleshooting). Something that many students need, and often lack now days.

in prep for later this week, i'm just throwing together a wiki page
that students will be able to follow with a bit of instructor
guidance:

http://www.crashcourse.ca/wiki/index.php/RCN_eewiki_BBB_page

  nothing really original but, as i mentioned, it breaks up the entire
process into a bunch of smaller and more manageable subtasks to let
students feel like they're making progress bit by bit, and makes
debugging much more focused if anything goes wrong.

rday

NOTE: if people insist on top-posting, then for the sake of brevity,
i'm going to wipe out everything below what i'm replying to. come on,
folks ... top-posting is really frowned upon.

  anyway, i'm currently going over RCN's kernel recipe for the BBB
using his "build_kernel.sh" script and i'm just going with the
defaults as they are, since my goal is simply to get a bootable
system. once all that's done, then i'll go back and look at tweaking
kernel options.

rday

Hi Robert,
Not all lists frown on top posting, most do not.

I'll try to explain the rationale from the position of having deal with many hundreds of emails a day encompassing diverse topics and lists in over 100 local email folders.

I am already familiar with the previous threads and do not have to read them again.

If someone bottom posts I ignore the top ones and scroll down to the latest comment as that is almost always all I need to completely understand the flow.

With a top post, I've got the message immediately.
Regards
Sid.

Thanks for the advice Robert!

I am currently working thru the same page, more or less as a student
:slight_smile: And you suggestions sound excellent. I would be interested to
hear you advice on selecting Kernel build options, from the menu. Do
you think there is such a thing as a "default" configuration ??

   NOTE: if people insist on top-posting, then for the sake of brevity,
i'm going to wipe out everything below what i'm replying to. come on,
folks ... top-posting is really frowned upon.

   anyway, i'm currently going over RCN's kernel recipe for the BBB
using his "build_kernel.sh" script and i'm just going with the
defaults as they are, since my goal is simply to get a bootable
system. once all that's done, then i'll go back and look at tweaking
kernel options.

rday

Hi Robert,
Not all lists frown on top posting, most do not.

Then most would be wrong.

I'll try to explain the rationale from the position of having deal with many
hundreds of emails a day encompassing diverse topics and lists in over 100
local email folders.

I am already familiar with the previous threads and do not have to read them
again.

Most people would not be. And if I'm reading an old post, I much
prefer comments in context to what they're referring too.

If someone bottom posts I ignore the top ones and scroll down to the latest
comment as that is almost always all I need to completely understand the
flow.

The goal is not to bottom post, it's to post within context.

With a top post, I've got the message immediately.

Sure, but out of context. Mailing list posts are not conversations
between 2 or 3 or 4 people, they are between participants and the
broader community. Only inline comments work.

However, in the new world of mobile, perhaps top posting isn't the
evil I've always believed it to be.

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 ...

rday

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.

Regards,
John

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.

rday

>
> 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