Commissioning of SOM over Ethernet

Lets assume I do just have the Ethernet interface of the Apalis TK1 available for the commissioning of the SOM with my customized full image. All information I found related to the commissioning of the SOM over Ethernet like this wiki article about flashing with TFTP over Ethernet assumes to beeing able to access the u-boot prompt prior to the flashing somehow over an interface other than Ethernet (via the serial console connected over the RS232, the serial interface connected over USB, etc.). How can I flash my full image onto a not yet flashed SOM over Ethernet? How can I access the u-boot prompt of a pre-flashed SOM over Ethernet?

Lets assume I do just have the Ethernet interface of the Apalis TK1 available for the commissioning of the SOM with my customized full image. All information I found related to the commissioning of the SOM over Ethernet like this wiki article about flashing with TFTP over Ethernet assumes to beeing able to access the u-boot prompt prior to the flashing somehow over an interface other than Ethernet (via the serial console connected over the RS232, the serial interface connected over USB, etc.).

Not at all. Who assumes that? The console/prompt is just one of them many ways to go about it. You may actually initiate the TFTP flashing by whatever means you design into your system. This may be some update GPIO checked upon boot or even initiated from the running Linux system via e.g fw-utils setting some U-Boot environment variables.

How can I flash my full image onto a not yet flashed SOM over Ethernet?

Well, that’s a different story. If it is not flashed at all (e.g. even missing a boot loader or having been briked during flashing for that matter) there is no way leading around having to use the USB recovery mode. How that is entered is again left to your creativity as the system designer. Of course once U-Boot runs on the module any further step may be realised over Ethernet.

How can I access the u-boot prompt of a pre-flashed SOM over Ethernet?

As mentioned before the console/prompt really has nothing to do with this.

Not at all. Who assumes that? The console/prompt is just one of them many ways to go about it. You may actually initiate the TFTP flashing by whatever means you design into your system. This may be some update GPIO checked upon boot or even initiated from the running Linux system via e.g fw-utils setting some U-Boot environment variables.

The statement about the console/prompt was addressing the capabilities of u-boot in the initial state of the official Apalis Linux Image. All approaches like the “mass production” like GPIO checking approach requires that an image which supports this in a customized bootloader or in a customized Linux is already flashed onto the SOM right after production and before assembling the SOM into the overall system like product housing etc., right? (I would consider an approach which requires booting into Linux as second/later choice.)

Well, that’s a different story. If it is not flashed at all (e.g. even missing a boot loader or having been briked during flashing for that matter) there is no way leading around having to use the USB recovery mode. How that is entered is again left to your creativity as the system designer. Of course once U-Boot runs on the module any further step may be realised over Ethernet.

This means it is required to have access to the recovery mode pins and the USB interface as easily as possible (from the outside of the product housing or from within the product housing), right?

So far our regular U-Boot does not support any kind of console/prompt over Ethernet.

Whether or not a certain product will allow/require using the USB recovery mode is left entirely up to the system designer to decide.

BTW: I believe I did mention this before. Volume production Apalis TK1 modules will most possibly only ship with the Toradex Easy Installer pre-installed which will allow for unattended auto updating from a network source as well.

I added a customized u-boot to the Apalis image which pings for a static host ip before booting. If there is some connection present it executes run setethupdate and run update. The conditional update execution does work like expected. If I disconnect the RS232 connection X29 (serial terminal for debugging) from the board during the flashing of e.g. the rootfs.ext-XXX files, waiting for some minutes and plugging it in again later the flashing continues after the last “package”. I expected to see some later package to be transfered because the update should be performed over the connected ethernet interface. How do I have do modify run setethupdate and run update to transfer the data over the ethernet interface (connector X12)?

Did I miss something about flashing over ethernet with relation to the website instructions http://developer.toradex.com/knowledge-base//knowlodge-base/flashing-linux-over-ethernet ?

EDIT: For this image version I watched the verbose debug info of the tftp server in the system log file to determine the correct point in time when to disconnect the board from Ethernet (that the updated image is not overridden again).

Well, have you ever run Ethernet aka TFTP updates on our stock BSP demo image? If not I suggest for you to start with that to make sure your infrastructure and understanding of things is proper.

Everything is working like expected.

I just had a very rare timing with relation to oberving the tftp package transmission: The update is re-triggered when the Ethernet cable keeps connected to the board after the first update with this same image. The image update has been re-triggered a second time and I just passed by for observing the tftp transmission when the exactly same rootfs.ext3-xxx has been transmitted :slight_smile: