I'm in the process of upgrading to a new image/kernel, and have many 
questions regarding best practices. My goal is to stay relatively current 
while spending most of my time on developing my application, not on doing 
upgrades; my success to date has been dismal. Over the past few weeks I 
have installed a new image (Debian Jessie 8.2) and am running the 
kernel 4.1.13-ti-r36. It has taken over three weeks just to get the 
networking running in a stable manner; I have been successful, but I don't 
think I was really doing anything totally foolish, it just took that long. 
I now am trying to go to the next steps, and after much googling/reading am 
finding the process extremely challenging (at least for me); I have more 
questions than answers. If someone can help, it would be appreciated.

1) What is best practices? I have seen references to Robert Nelson's 
"manual", but can't find where it is (I have 
browsed https://github.com/RobertCNelson/ but so far can't find it). I have 
found many sites such 
as http://elinux.org/Beagleboard:BeagleBoneBlack_Debian, which has many 
snippets, but it assumes one knows what is going on; for example, it points 
to http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-11-03 as being 
the most recent version, but this looks old.

2) My version, seems to be part of the "TI" branch, but I have seen when 
googling that this branch requires numerous kernel upgrades.

"TI BSP

*WARNING*: do not use if you are not use to re-basing git branches, as this 
is based on 
http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.1.y
 instead 
of a stable kernel branch. Thus you will have to do: (git checkout master 
-f ; git branch -D tmp ; git pull ; git checkout origin/ti-linux-4.1.y -b 
tmp) often..

"

 Would it be better to use a "more stable" branch? Some branches also have 
RT in their name; I assume this stands for real-time? Is this version a 
good choice? how does one use the "real-time" capabilities? I can't, to 
date, find a site that recommends "Best Practices" in which kernel and 
kernel updates to use.

3) I have seen two methods for changing the kernel
a)
> cd /opt/scripts/tools
> ./update_kernel.sh --kernel "kernel_name"
I assume after this, one reboots? Where does one find what kernels are 
available; what is best to use for "kernel_name"? which ones should be 
used? can one go back and forth without repercussions?
The other method I have seen is using apt-get such as
>sudo apt-get install linux-image-3.14.17-ti-r10 
Which method is preferred? Are there pros and cons? Again, can one go back 
and forth? And which kernels are available?

Can one stay relatively up to date without re-flashing the complete eMMC 
and re-installing everything as this takes over a month full-time (for me, 
sigh!), just by doing apt-get upgrades and installing new kernels? How does 
know when to update the kernel and which one to use?

4) Doing an >apt-cache search kernel shows well over a hundred choices for 
"linux-firmware-image...", "linux-headers-...", "linux-image-..." etc. 
Which ones should be used? What is the difference between the three 
choices? Is there a site which recommends the best current choice?

I have been using the BBB's on and off for almost two years now (mostly on) 
and still have real problems and have to commit large amounts of time 
trying to stay current. I'm guessing I may be doing something fundamentally 
wrong; but I can't imagine how someone just getting started could navigate 
this issue. Could  this difficulty possibly be something that is keeping 
the BBB's from getting popular?

In summary, if someone knowledgeable in this area could give guidelines on 
how best to stay current in an efficient manner, it would be appreciated.

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

Reply via email to