Rewrote U-Boot Installation section.
My primary goal here was to put the text into a consistent voice, and convert the text to a more flowing narrative rather than a step-by-step list. In a few places, I added commentary on the process where it seemed appropriate, but I strove to keep that minimal. Finally, labels to some unlabeled sections of gpl-lgpl.tex were needed for back-references used in my rewrite.
This commit is contained in:
parent
3ee46d6770
commit
0a37731b72
2 changed files with 113 additions and 96 deletions
|
@ -633,110 +633,123 @@ u-boot to your router'', which reads:
|
|||
\end{enumerate}
|
||||
\end{quotation}
|
||||
|
||||
At this point in the installation process, hitting a key failed to interrupt
|
||||
the boot process and yield the \verb0hornet>0 prompt. For the investigator,
|
||||
this became a moment of consideration: is this
|
||||
|
||||
However, the investigator was only able to read data from the serial port; the
|
||||
investigator was unable to send key events via the serial port so the U-Boot
|
||||
console could not be accessed in that way. The investigator did find another
|
||||
way of accessing the U-Boot console, though, which was used to complete the
|
||||
U-Boot installation and verification. The likely issue with the serial port was
|
||||
initial mis-wiring of the serial connector, causing the receive pin to be
|
||||
permanently disabled. Here are the steps the investigator tried, including the
|
||||
alternate method of installation that did not require the serial console:
|
||||
%FIXME: image of the serial cable available anywhere to put here:
|
||||
% https://www.adafruit.com/images/970x728/954-02.jpg
|
||||
|
||||
The investigator used the purchased serial cable, which was a USB serial
|
||||
adapter with a male USB type A connector to 4 female jumper wires. The
|
||||
female jumper wires were red, black, white, and green.
|
||||
|
||||
The instructions here were slightly incomplete, since they did not specify
|
||||
how to connect the wires to the router. However, the investigator found
|
||||
general information available online at
|
||||
\url{http://wiki.openwrt.org/toh/tp-link/tl-wr841nd#serial.console} which
|
||||
described the proper procedure. While the ``power'' and ``ground'' cables
|
||||
were obvious, some trial and error was necessary to find the RX and TX
|
||||
cables, but this was easily determined since miswiring TX and RX yields no
|
||||
I/O and proper wiring yields the output as expected. Using the pin gender
|
||||
changer included with the adapter, the investigator was able to stably wire
|
||||
the pins for use once the proper RX and TX connections were determined.
|
||||
|
||||
The investigator then used the recommended 115200 8N1 for serial console
|
||||
settings, leaving all flow control off, and tested both with the
|
||||
\verb0minicom0 and \verb0screen0 commands. The investigator found that if
|
||||
all 4 wires were connected on the USB serial adapter that the router would
|
||||
start without additional power and the console would receive the startup
|
||||
messages. The investigator could replicate the same behavior by omitting the
|
||||
power cable from the USB serial adapter (red wire) and connecting the main
|
||||
power adapter to the router instead.
|
||||
|
||||
At this point, the on-screen messages as described in the installation
|
||||
instructions appeared, but the investigator found that no key events sent via
|
||||
the serial port appeared to reach the U-Boot console. In other words, while
|
||||
the investigator saw both U-Boot and kernel boot messages in the serial
|
||||
console, the investigator was unable to interrupt the boot process as
|
||||
instructed by ``u-boot\verb0_0reflash''. Hitting a key simply did
|
||||
\texit{not} interrupt the boot process and yield the \verb0hornet>0 prompt.
|
||||
|
||||
After additional trial and error over a period of hours, the investigator had
|
||||
finally to consider this question for the first time during the process:
|
||||
``Has ThinkPenguin violated the GPL?'' More specifically, the immediate
|
||||
question was: ``Given this failure, has the distributor met
|
||||
\hyperref{GPLv2s3-build-scripts}{the requirements for `scripts used to
|
||||
control \ldots installation of the executable' (GPLv2)} and
|
||||
\hyperref[GPLv3-installation-information]{necessary `Installation
|
||||
Information' (GPLv3)}?''
|
||||
|
||||
The answer to the question; however, is (at this specific stage), ``possibly,
|
||||
but more information is needed''. Embedded installation and configuration is
|
||||
a tricky and complex technical process. While the GPL requires documentation
|
||||
and clear instructions for this process, immediately blaming the distributor
|
||||
for honest, correctable mistakes, or issues legitimately explained by
|
||||
feasible alternative theories.
|
||||
|
||||
In this case, upon remembering the issues of wiring, the investigator wonder
|
||||
if perhaps the power pin was accidentally connected for a moment to the RX
|
||||
pin while live. Such action could easily fry the RX pin, and yield the
|
||||
observed behavior. Since the investigator could not rule out the possibility
|
||||
of accidental connection of power to the RX pin mentioned, the investigator
|
||||
had to assume the instructions would work properly if he had not made that
|
||||
error.
|
||||
|
||||
That conclusion, while correct, also left the investigator with only two
|
||||
option to complete the final verification of the CCS:
|
||||
|
||||
\begin{itemize}
|
||||
|
||||
\item The investigator found the serial cable included was a USB serial adapter
|
||||
that had a male USB type A connector on one end and 4 female jumper wires at the
|
||||
other end. These female jumper wires were red, black, white, and green.
|
||||
\item Purchase a new router and cable anew, and reattempt the installation
|
||||
process while taking extra care not to miswire any cables.
|
||||
|
||||
\item The instructions did not specify how to connect these wires, but the
|
||||
investigator was able to determine this in part using the "v8.4" image (close to
|
||||
the "v8.2" version string the investigator found on the bottom of the router) at
|
||||
\url{http://wiki.openwrt.org/toh/tp-link/tl-wr841nd#serial.console} . Aside
|
||||
from power and ground (red and black), the investigator did have to guess which
|
||||
of the wires was RX and TX. By experimentation the investigator found that
|
||||
green was RX and white was TX. When the investigator tried the other way, no
|
||||
data was received to the serial console at boot time. While determining which
|
||||
wires connected to which pins, the investigator may have connected the power pin
|
||||
to the RX pin; this could explain why the receive (RX) pin later failed to work.
|
||||
|
||||
\item The investigator did have to use the included jumper pin gender changer
|
||||
with the USB serial adapter, which the investigator put through the holes on the
|
||||
router's mainboard and then connected to the USB serial adapter. The fit was
|
||||
fairly loose so it would be nice if future router versions included a tighter
|
||||
gender changer or (ideally) had the jumper pins soldered onto the board to begin
|
||||
with (so no gender changer would be required). Since the serial cable is not
|
||||
strictly required for U-Boot installation (see below), this may not be issue.
|
||||
|
||||
\item The investigator used 115200 8N1 as the serial console setting (with no
|
||||
hardware or software flow control). This was tested with both the
|
||||
\verb0minicom0 and \verb0screen0 commands. The investigator found that if all 4
|
||||
wires were connected on the USB serial adapter that the router would start
|
||||
without additional power and the console would receive the startup messages.
|
||||
The investigator could replicate the same behavior by omitting the power cable
|
||||
from the USB serial adapter (red wire) and connecting the main power adapter to
|
||||
the router instead.
|
||||
|
||||
\item While the investigator did see the U-Boot and kernel boot logs in the
|
||||
serial console, the investigator was unable to interrupt the boot process as
|
||||
u-boot\verb0_0reflash indicated one should. This is likely related to the
|
||||
accidental connection of power to the RX pin mentioned earlier, which may have
|
||||
disabled the pin, preventing the serial port on the router from receiving the
|
||||
commands sent to it.
|
||||
|
||||
\item The investigator then contacted one of the libreCMC developers to
|
||||
determine what the serial console issue might be and whether there was an
|
||||
alternate way to install U-Boot that did not rely on the serial console working.
|
||||
The developer agreed the the receive pin had likely been disabled so a different
|
||||
installation method would be needed. The developer indicated that the console
|
||||
could be accessed via \verb0netcat0 when the router was booted into a special
|
||||
mode by holding the reset button on the router for 7 seconds after turning on
|
||||
the router.
|
||||
|
||||
\item The investigator turned on the router while pressing reset as mentioned
|
||||
above and then ran \verb0nc -u -p 6666 192.168.1.1 66660 on the desktop that was
|
||||
connected to the router (after changing its IP address to 192.168.1.2). After
|
||||
pressing Enter, a \verb0uboot>0 prompt appeared and the investigator was able to
|
||||
confirm the running version by typing \verb0version0 to which the router
|
||||
responded with "U-Boot 1.1.4 (Jul 28 2014)".
|
||||
|
||||
\item A TFTP server was then setup according to step 1 of the U-Boot
|
||||
installation steps in u-boot\verb0_0reflash. These instructions did not
|
||||
explicitly state that the U-Boot image mentioned in step 4 of the build
|
||||
instructions should be placed in /srv/tftp, but this was evident based on the
|
||||
instructions that followed. This should be corrected in a future version of
|
||||
u-boot\verb0_0reflash but, because it was straight-forward based on the context,
|
||||
did not amount to a compliance issue.
|
||||
|
||||
\item The u-boot\verb0_0reflash steps were then followed starting at step 4,
|
||||
using the \verb0netcat0 console rather than the serial console (described in
|
||||
steps 2 and 3). The U-Boot image was downloaded onto the device and then copied
|
||||
over top of the old U-Boot image. The router was then restarted with the
|
||||
\verb0reset0 command.
|
||||
|
||||
\item Since the serial cable was still connected, the investigator noticed at
|
||||
startup that U-Boot now printed "U-Boot 1.1.4 (Oct 17 2014)" as its version
|
||||
string. This was also confirmed by using the \verb0netcat0 console and the
|
||||
\verb0version0 command, as was previously done above. The new version string
|
||||
showed that the router was now running the version of U-Boot that the
|
||||
investigator built, rather than the one it was shipped with, thus fulfilling the
|
||||
GPL's requirements that one must be able to build and install the software and
|
||||
any modified versions.
|
||||
\item Seek assistance from the libreCMC community to find an alternative
|
||||
method of installation.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
While the u-boot\verb0_0reflash instructions appear to be functional for those
|
||||
able to use a serial console, we would prefer if these instructions were updated
|
||||
to use the \verb0netcat0 console instead. This provides a number of advantages,
|
||||
such as no requirement for additional hardware to install a new version of
|
||||
U-Boot, and less chance of mis-configuring one's serial connector (which would
|
||||
reduce the risk of damage to the router). The existing instructions appear to
|
||||
be compliant without modification; this suggestion would merely make it easier
|
||||
for users to take advantage of the freedoms provided to them by U-Boot and the
|
||||
rest of the system.
|
||||
The investigator chose the latter and then contacted a libreCMC developers
|
||||
familiar with the product. That developer, who agreed the the RX pin was
|
||||
likely ruined, described an alternative method for console access using the
|
||||
{\tt netcat}. The method described was:
|
||||
|
||||
\begin{quotation}
|
||||
|
||||
\begin{itemize}
|
||||
|
||||
\item Change the IP address of the router to 192.168.1.1.
|
||||
|
||||
\item Change the IP address of a desktop GNU/Linux system to 192.168.1.2.
|
||||
|
||||
\item Power on the router while holding the reset button for 7 seconds.
|
||||
|
||||
\item Use the {\tt netcat} command (as below) on the desktop, and press
|
||||
enter to receive U-Boot's prompt:
|
||||
|
||||
\lstset{tabsize=2}
|
||||
\begin{lstlisting}[language=bash]
|
||||
$ nc -u -p 6666 192.168.1.1 6666
|
||||
uboot>
|
||||
\end{lstlisting}
|
||||
\end{itemize}
|
||||
\end{quotation}
|
||||
|
||||
Upon following this procedure, the investigator was able to confirm the
|
||||
(original) version:
|
||||
\begin{lstlisting}[language=bash]
|
||||
$ nc -u -p 6666 192.168.1.1 6666
|
||||
uboot> version
|
||||
U-Boot 1.1.4 (Jul 28 2014)
|
||||
\end{lstlisting}
|
||||
|
||||
Thereafter, the investigator followed the instructions as original specified
|
||||
in ``u-boot\verb0_0reflash''. The investigator configured a TFTP server,
|
||||
placed the newly built firmware into \textt{/srv/tftp}. The investigator
|
||||
then followed the remaining instructions in ``u-boot\verb0_0reflash'' as
|
||||
written, using the \textt{netcat} console rather than the serial console, and
|
||||
used U-Boot's \texttt{reset} command to reboot the router.
|
||||
|
||||
Upon reboot, the serial console (still connect with working output) showed
|
||||
the message \texttt{U-Boot 1.1.4 (Oct 17 2014)}, and thus confirmed a
|
||||
successful reflash of the U-Boot image built by the investigator.
|
||||
|
||||
\section{Firmware Comparison}
|
||||
|
||||
|
|
|
@ -1757,6 +1757,8 @@ exercise her freedoms to modify and redistribute changes. Without the
|
|||
complete source, it would not be possible to make changes that were
|
||||
actually directly derived from the version received.
|
||||
|
||||
\label{GPLv2s3-build-scripts}
|
||||
|
||||
Furthermore, GPLv2~\S3 is defending against a tactic that has in fact been
|
||||
seen in GPL enforcement. Under GPL, if you pay a high price for
|
||||
a copy of GPL'd binaries (which comes with corresponding source, of
|
||||
|
@ -3108,6 +3110,8 @@ labeling what is demonstrably a consumer product in ways that suggest it is
|
|||
|
||||
\subsubsection{Installation Information}
|
||||
|
||||
\label{GPLv3-installation-information}
|
||||
|
||||
With the User Products definition complete, The ``Installation Information''
|
||||
definition uses that to define what those receiving object code inside a User
|
||||
Product must receive.
|
||||
|
|
Loading…
Reference in a new issue