Category: Provisioning

Provisioning: Using Serial Download Protocol (SDP) – Part 2

In our previous post, we have explored basic details about Introduction to Provisioning and it’s needs. In this post we will narrow down our use case and experiment how it works. As mentioned in our previous post, we will use

 

Hardware: Phytec Phycore imx6UL/ULL SoM

Storage: eMMC

 

We will assume that the hardware is shipped without any software (bootloader). If the hardware is shipped with Bootloader and BSP, then we need to force the hardware to boot from Serial Download Mode (SDP) using boot switch. Refer to imx6UL/ULL datasheet and Technical Reference manual to know more about boot mode selection.

 

imx6UL/ULL primarily comes with 2 USB OTG controllers and to use SDP, we need to use OTG1 controller. Setup to get into SDP is,

  • Connect the USB OTG to the host machine (Raspberry PI in our case)
  • Connect debug UART to see the functional booting of the target

When in SDP mode, connecting USB OTG enumerates the Freescale imx6UL/ULL device below (seen using lsusb)

Bus 001 Device 007: ID 15a2:0080 Freescale Semiconductor, Inc.

When expanded with we have,

To detail, Freescale USB device enumerated with one configuration with one Interrupt Endpoint. SDP protocol uses this USB configuration (interrupt endpoint) to communicate with the SoC and upload images over USB. This is implemented as open source imx_usb_loader. In our case, I have cloned and compiled the latest version from Github. This utility depends on libusb.

 

The most important part of imx USB loader is imx_usb.conf,

pi@raspberrypi:~/imx_usb_loader $ cat imx_usb.conf
#vid:pid, config_file
0x066f:0x3780, mx23_usb_work.conf
0x15a2:0x004f, mx28_usb_work.conf
0x15a2:0x0052, mx50_usb_work.conf
0x15a2:0x0054, mx6_usb_work.conf
0x15a2:0x0061, mx6_usb_work.conf
0x15a2:0x0063, mx6_usb_work.conf
0x15a2:0x0071, mx6_usb_work.conf
0x15a2:0x007d, mx6_usb_work.conf
0x15a2:0x0080, mx6ull_usb_work.conf
0x1fc9:0x0128, mx6_usb_work.conf
0x15a2:0x0076, mx7_usb_work.conf
0x1fc9:0x0126, mx7ulp_usb_work.conf
0x15a2:0x0041, mx51_usb_work.conf
0x15a2:0x004e, mx53_usb_work.conf
0x15a2:0x006a, vybrid_usb_work.conf
0x066f:0x37ff, linux_gadget.conf
0x1b67:0x4fff, mx6_usb_sdp_spl.conf
0x1b67:0x5ffe, mx6_usb_sdp_spl.conf
0x0525:0xb4a4, mx6_usb_sdp_spl.conf
0x1fc9:0x012b, mx8mq_usb_work.conf
0x1fc9:0x0134, mx8mm_usb_work.conf
0x3016:0x1000, mx8mm_usb_sdp_spl.conf

which stores the USB Vendor ID and Product ID and use respective configuration. Highlighted in RED is the Phytec’s imx6ULL SoC.

Loading U-boot bootloader image:

We are going to compile and load U-Boot using imx_usb_loader. To do so, we need to compile u-boot with SDP support. The mainline U-Boot version supports our board Phycore imx6UL/ULL and SDP is implemented as part of U-Boot. Please refer steps to compile u-boot and configuration option for your board/SoC in U-Boot documentation.

Configuration using: make ARCH=arm menuconfig

enable SDP in SPL and also in U-Boot and cross compile for ARM. Outcome of the compilation will be two images,

  • SPL – Secondary Program Loader (Executed directly by imx6 ROM Code)
  • U-Boot proper – Loaded by SPL

To load SPL first using imx_usb_loader,

sudo ./imx_usb ./SPL ./imx_usb.conf

which will load SPL into RAM and imx6 ROM code will start it. The next step is to load the U-Boot proper using,

sudo ./imx_usb ./u-boot-dtb.img ./imx_usb.conf

We can observe the same in imx6 targets UART Debug console,

U-Boot SPL 2019.10-00341-gffc379b42c-dirty (Oct 26 2019 - 21:54:46 +0200)
Trying to boot from USB SDP
SDP: initialize...
SDP: handle requests...
Downloading file of size 382 to 0x81000000... done
Downloading file of size 22262368 to 0x82000000... done
Downloading file of size 410113 to 0x877fffc0... done
Jumping to header at 0x877fffc0
Header Tag is not an IMX image

U-Boot 2019.10-00341-gffc379b42c-dirty (Oct 26 2019 - 21:54:46 +0200)

CPU: Freescale i.MX6ULL rev1.0 792 MHz (running at 396 MHz)
CPU: Industrial temperature grade (-40C to 105C) at 46C
Reset cause: POR
Model: Phytec phyBOARD-i.MX6ULL-Segin SBC
Board: PHYTEC phyCORE-i.MX6ULL
DRAM: 256 MiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1
In: serial@2020000
Out: serial@2020000
Err: serial@2020000
Net:
Warning: ethernet@2188000 using MAC address from ROM
eth0: ethernet@2188000
Hit any key to stop autoboot: 0

Conclusion:

In this post we have viewed the basic details about SDP and it’s working when loading U-Boot using imx_usb_loader. In the next post we will explore in details about the Vendor ID and Product ID usage in U-Boot proper and relative configuration in imx_usb_load. This will help further to achieve our goal of automated flashing.

Provisioning Embedded Linux – Part 1

Development of various Embedded Hardware in market based on various architectures are currently available as various consumer to industrial solutions. Hardware manufacturer also provide Board Supported Package (BSP) to get the hardware up and running with basic system software. Based on various requirements and use cases, these software are engineered in various ways and customized for specific purposes. Deployment of software to those hardware can be achieved in various ways based on hardware and System on Chip (SoC).

 

What is Provisioning?

Custom hardware are build and manufactured and then shipped to customer. But the deployment of software also needs to be done after the production. Usually the hardware come out of production will be bare meta (without any software) and in some cases, the manufacturer or vendor will flash basic Bootloader to get the software deployment started. In both the case, the deployment of software is a separate task and we call it as Provisioning.

 

Problem with Provisioning

The main challenge which is faced during provisioning is to handle multiple targets at the same time. Companies often need to ship millions of units to customers within weeks or in small use cases, this range will around hundreds. Large manufacturing and provisioning chain also includes automated mechanisms to flash the software to storage. In some cases, storage units like eMMC are pre-flashed before deploying/placing it in actual custom hardware. But having such setup is time consuming and not cost effective. Companies which supplies hardware in hundreds will not be able to have such huge setup and tend to involve huge manual efforts to get the hardware provisioned.

 

Use case:

As provisioning the bare metal hardware is specific to hardware or SoC, we will narrow down the real use case for below hardware platform.

Hardware Platform: Phytec Phycore imx6UL/ULL

Primary Storage: eMMC

 

Serial Download Protocol (SDP):

To understand our use case and provisioning process, we need to first understand the Freescale imx6 boot process. This is well documented as part imx6 Technical Reference Manual Chapter 8: System Boot and also there are many articles in internet which explains the boot process.

The overview of boot process is, when the SoC is powered the Boot ROM code will kick start and will look for bootable image from storage mediums like SD, eMMC and so on. If ROM finds correct bootable image, it will load the image into SRAM (inside SoC) or RAM based on configuration and execute it. It most cases the first program to load and run will be bootloader (like U-Boot, Barebox).

In case of newly manufactured hardware without pre-flashed software, there is special software loading option which is present in imx6, which is Serial Download Protocol (SDP) i.e in short Serial loading of software. When ROM couldn’t find any software in all the boot medium it will enter into SDP mode. Typically SDP can be achieved over UART and USB, so the boot ROM will look for bootable image by scanning the USB and UART.

 

Conclusion

Bare metal hardware can be loaded with bootable image using Serial Download Protocol and further our actual production/deployment image can be flashed into storage mediums like SD, eMMC. We will explore this in detail with necessary tools by manually loading and provisioning it. Later we will extend this solution in cheap or low cost automated way.