Tutorial How-to: Booting U-Boot and Linux over USB

katadelos · 08-22-2021, 11:58 AM

Description
This how-to covers the process of booting stock or self compiled U-Boot and Linux binaries over USB using Serial Download Protocol.

SDP allows a developer to test that binaries function as expected without needing to flash them to eMMC storage, which reduces the risk of bricking the test device and extends the life of the eMMC storage by avoiding unnecessary write cycles.

Compatibility
This how-to is applicable to Kindle devices that do not implement the Secure Boot feature of the SoC (i.e all devices up to and including KT3).

Process
Almost all Kindle devices support the use of Serial Download Protocol. This is a low-level, built-in feature of the Freescale/NXP SoC used on Kindle devices that allows the user to load and execute arbitrary code via a USB connection. SDP is likely used during the device manufacturing process to flash the initial firmware image and has also been utilised by the MobileRead community as part of the Kubrick recovery system.

Activating Serial Download Protocol
SDP can be activated in at least 3 ways, depending on the device:

SDP mode will be activated by the SoC as a fallback if a functional bootloader is not found. This has been observed by users who have mistakenly erased the eMMC storage of their devices
On some devices, SDP mode can be activated by applying 3.3v to a test/manufacturing point on the PCB. This test point has been observed on KT2, KT3, PW2 and PW3 and may exist on additional devices.
On older devices, SDP mode can be activated by a special key sequence known as the "Magic Key". More information can be found here.

It may be possible to activate SDP directly from Linux by writing the required boot mode value directly to the required hardware register and executing a soft reset, but this has not been tested.

Fallback method
SDP as a SoC fallback method can be activated by erasing a small section at the beginning of the eMMC storage, which will intentionally break the bootloader. This method is semi-permanent, meaning that the device will always boot into SDP mode until a U-Boot build is reinstalled to the device.

It is strongly recommended that developers create backups of the /dev/mmcblk0boot* sectors and transfer these backups to a safe location first.

Code:

# Backup original boot partitions
dd if=/dev/mmcblk0boot0 of=/mnt/us/mmcblk0boot0
dd if=/dev/mmcblk0boot1 of=/mnt/us/mmcblk0boot1
# Zero 128KB of /dev/mmcblk0boot0
dd if=/dev/zero of=/dev/mmcblk0boot0 bs=128K count=1

Manufacturing point method
For this method, a 3.3v source is required- this can be found on most USB-UART adapters and microcontroller boards (ESP32/8266, Arduino etc). It has been confirmed that the 1.8v source at TP1706 will also work on KT2.

KT2, PW2, PW3: Connect a wire from your voltage source to TM401 and reset the device.
KT3: Connect a wire from your voltage source to the pad specified in this thread and reset the device.

On some devices, it is possible to activate SDP mode without connecting directly to the manufacturing point, making it unnecessary to remove the PCB from the device:

KT2: See this thread
PW2 & PW3: CR501, right side

When SDP mode is active, it will be detected as a SE Blank * device manufactured by Freescale SemiConductor:

Code:

Bus 003 Device 039: ID 15a2:0063 Freescale Semiconductor, Inc.

Code:

[ 5574.623011] usb 3-10.1: new high-speed USB device number 39 using xhci_hcd
[ 5574.823870] usb 3-10.1: New USB device found, idVendor=15a2, idProduct=0063, bcdDevice= 0.01
[ 5574.823877] usb 3-10.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 5574.823880] usb 3-10.1: Product: SE Blank MEGREZ
[ 5574.823883] usb 3-10.1: Manufacturer: Freescale SemiConductor Inc 
[ 5574.825931] hid-generic 0003:15A2:0063.0012: hiddev0,hidraw0: USB HID v1.10 Device [Freescale SemiConductor Inc  SE Blank MEGREZ] on usb-0000:00:14.0-10.1/input0

Loading binaries using imx_usb_loader
After SDP mode has been enabled, the device can be accessed from a Linux host using a tool called imx_usb_loader.

This tool is packaged and available on most mainstream Linux distributions and can be installed on an Ubuntu system using the command below:

Code:

sudo apt install imx-usb-loader

Loading a U-Boot binary
A U-Boot binary can be loaded by executing the command below:

Code:

sudo imx_usb u-boot.bin

This command may give an error similar to the one below depending on your device, imx_usb build and u-boot binary:

Code:

config file <.//mx6_usb_work.conf>
parse .//mx6_usb_work.conf
Trying to open device vid=0x15a2 pid=0x0063
Interface 0 claimed
HAB security state: development mode (0x56787856)
== work item
filename ../u-boot.bin
load_size 0 bytes
load_addr 0x00000000
dcd 1
clear_dcd 0
plug 1
jump_mode 3
jump_addr 0x00000000
== end work item
No DCD table

loading binary file(../u-boot.bin) to 00980000, skip=0, fsize=1a1e4 type=aa

<<<106980, 106980 bytes>>>
succeeded (security 0x56787856, status 0x88888888)
jumping to 0x00980400
do_command err=-1, last_trans=0
do_command err=-1, last_trans=0
do_command err=-1, last_trans=0
do_command err=-1, last_trans=0
do_command err=-1, last_trans=0
config file <.//mx6_usb_work.conf>
parse .//mx6_usb_work.conf
Trying to open device vid=0x15a2 pid=0x0063
Interface 0 claimed
do_command err=-1, last_trans=0
do_command err=-1, last_trans=0
do_command err=-1, last_trans=0
do_command err=-1, last_trans=0
do_command err=-1, last_trans=0
status failed

This error can be safely ignored and is explored in more detail in the "Loading a Linux binary" section.

Loading a Linux binary
imx_usb_loader is also capable of loading a U-Boot image and Linux kernel (and in theory, a rootfs) at the same time. This requires some additional customisation and configuration, depending on the U-Boot version.

Generating a DCD table
On Freescale/NXP SoC, peripheral and DRAM initialisation is handled using data structures known as DCD tables. Older versions of U-Boot (e.g uboot-2009.08-lab126) handle DCD tables in a different manner than later versions. Instead of being contained within a separate imximage.cfg file that is integrated into the final U-Boot image after compilation, they are located within the flash_header.S file for that board.

On versions that use flash_header.S, the DCD data is structured like so:

Code:

MXC_DCD_ITEM(2, IOMUXC_BASE_ADDR + 0x5c0, 0x00020000)

Each MXC_DCD_ITEM consists of a node ID, a write address to and a value. This needs to be converted to the format below:

Code:

DATA 4 0x20e05c0 0x00020000    #2

The main difference is that the write address needs to be defined explicitly, which can be achieved by identifying the *_BASE_ADDR for that item and adding the offset.

Disabling header appending
As DCD initialisation can only be carried out once during each boot cycle, the developer needs to disable the flash header within the defconfig for their device:

Code:

diff --git a/include/configs/imx60_wario_mfgtool.h b/include/configs/imx60_wario_mfgtool.h
index c7c1ad1..41a05b4 100644
--- a/include/configs/imx60_wario_mfgtool.h
+++ b/include/configs/imx60_wario_mfgtool.h
@@ -29,8 +29,8 @@
 #define CONFIG_MX6SL_ARM2
 #define CONFIG_WARIO
 #define CONFIG_WARIO_BASE
-#define CONFIG_FLASH_HEADER
-#define CONFIG_FLASH_HEADER_OFFSET 0x400
+//#define CONFIG_FLASH_HEADER
+//#define CONFIG_FLASH_HEADER_OFFSET 0x400
 #define CONFIG_MX6_CLK32          32768
 
 #include <asm/arch/mx6.h>

Changing boot command
By default, U-Boot will attempt to load a Linux binary from eMMC storage. To load a Linux binary that has been pre-loaded into memory, we need to change the memory location that U-Boot attempts to load from:

Code:

diff --git a/include/configs/imx60_wario_mfgtool.h b/include/configs/imx60_wario_mfgtool.h
index c7c1ad1..ed23fde 100644
--- a/include/configs/imx60_wario_mfgtool.h
+++ b/include/configs/imx60_wario_mfgtool.h
@@ -218,7 +218,7 @@
 #define CONFIG_BISTCMD_MAGIC   0xBC 
 
 #define        CONFIG_EXTRA_ENV_SETTINGS \
-    "bootcmd=bootm " MK_STR(CONFIG_MMC_BOOTFLASH_ADDR) "\0" \
+    "bootcmd=bootm " MK_STR(CONFIG_LOADADDR) "\0" \
     "failbootcmd=panic\0" \
     "post_hotkeys=0\0" \
     "loglevel=5\0" \

Creating IMX image
Once a DCD table in the new format has been created, it needs to be joined to the main U-Boot binary:

Code:

mkimage -n wario-dcd.cfg -T imximage -e 0x80500000 -d mfgtool.bin u-boot-dcd.imx

Creating configuration file
To load a Linux binary using imx_usb, the developer will need to create a custom configuration file:

Code:

# mx6_usb_work_wario.conf
KindleTouch2
hid,1024,0x910000,0x70000000,256M,0xF8000000,128K
u-boot-dcd.imx:dcd
uImage-KT2-stock:load 0x80800000
u-boot-dcd.imx:clear_dcd,load,jump header

The configuration file above will carry out the following tasks:

The DCD table within u-boot-dcd.imx will be loaded and executed to initialise the device
uImage-KT2-stock will be loaded to 0x80800000
The DCD table will be cleared, the entire U-Boot binary will be loaded into memory and the SoC will then jump to the U-Boot execution address

If the U-Boot binary has been correctly configured, it will then attempt to load the uImage which has been loaded into memory instead of the uImage contained within the flash storage of the device.

nicolasmart · 10-13-2021, 05:00 PM

Hey again!

My KT2 was working gracefully until I let its battery fall down to 0%. I didn't let it fall down that low for quite a while but now it did. When I charged it back up it kicked into DIAGS. I tried doing anything useful - enable usbnet simply did nothing. I could go into fastboot and back but nothing really happened. Tried reflashing kernel with fastboot - didn't help.
Yes, I did try fastboot setvar bootmode main. I tried factory resetting. I tried updating to the latest version - pasting the update binary into storage and restarting actually did trigger an update and in the end it said "Update successful!" but once again it kicked into diags. Yes, there was a device_info.xml in diagnostics_logs. I tried setting the bootmode variable to reset and then it completely died.

No DIAGS. No screen update. Triggering SDP works but reflashing the only 2 uBoot images i have just triggers a disconnect. Is there any useful way for me to make it reflash the entire thing?

Thanks in advance!

nicolasmart · 10-14-2021, 04:13 AM

UPDATE!

Got it working again! For people who somehow got into the same situation:

I compiled a custom u-boot.bin based on the official 5.6.0 sources that runs "bist fastboot" whenever it detects a bootmode of reset. (After that I was able to change the bootmode var to main and for some reason it miraculously worked ???)

This was an enjoyable journey as I learned some new things in the process.

For people with compile errors when building a u-boot image: unfortunately they're meant to be built with gcc-4.4 or lower. It was a hassle finding arm-linux-gnueabi-gcc-4.4 but it is in the Ubuntu Precise old-releases repo and by disabling mandatory repo authentication - you can install it.

If anyone for some reason needs the exact binary for KT2: i've attached it to this post.

nicnic2001 · 08-21-2023, 01:20 PM

I do the reset and get to the bit where I have "Product: SE Blank MEGREZ" shown in dmesg. I run imx_usb_loader with uboot fastboot image found here: https://www.mobileread.com/forums/sh...d.php?t=342535 and I get a USB disconnect in dmesg but nothing after this... any ideas?

08-22-2021, 11:58 AM	#1
katadelos rm -rf / Posts: 219 Karma: 3333683 Join Date: Nov 2019 Location: United Kingdom Device: K5, KT, KT2, KT3, KT4, KV, PW2, PW3, PW4, PW5	How-to: Booting U-Boot and Linux over USB Description This how-to covers the process of booting stock or self compiled U-Boot and Linux binaries over USB using Serial Download Protocol. SDP allows a developer to test that binaries function as expected without needing to flash them to eMMC storage, which reduces the risk of bricking the test device and extends the life of the eMMC storage by avoiding unnecessary write cycles. Compatibility This how-to is applicable to Kindle devices that do not implement the Secure Boot feature of the SoC (i.e all devices up to and including KT3). Process Almost all Kindle devices support the use of Serial Download Protocol. This is a low-level, built-in feature of the Freescale/NXP SoC used on Kindle devices that allows the user to load and execute arbitrary code via a USB connection. SDP is likely used during the device manufacturing process to flash the initial firmware image and has also been utilised by the MobileRead community as part of the Kubrick recovery system. Activating Serial Download Protocol SDP can be activated in at least 3 ways, depending on the device: SDP mode will be activated by the SoC as a fallback if a functional bootloader is not found. This has been observed by users who have mistakenly erased the eMMC storage of their devices On some devices, SDP mode can be activated by applying 3.3v to a test/manufacturing point on the PCB. This test point has been observed on KT2, KT3, PW2 and PW3 and may exist on additional devices. On older devices, SDP mode can be activated by a special key sequence known as the "Magic Key". More information can be found here. It may be possible to activate SDP directly from Linux by writing the required boot mode value directly to the required hardware register and executing a soft reset, but this has not been tested. Fallback method SDP as a SoC fallback method can be activated by erasing a small section at the beginning of the eMMC storage, which will intentionally break the bootloader. This method is semi-permanent, meaning that the device will always boot into SDP mode until a U-Boot build is reinstalled to the device. It is strongly recommended that developers create backups of the /dev/mmcblk0boot* sectors and transfer these backups to a safe location first. Code: # Backup original boot partitions dd if=/dev/mmcblk0boot0 of=/mnt/us/mmcblk0boot0 dd if=/dev/mmcblk0boot1 of=/mnt/us/mmcblk0boot1 # Zero 128KB of /dev/mmcblk0boot0 dd if=/dev/zero of=/dev/mmcblk0boot0 bs=128K count=1 Manufacturing point method For this method, a 3.3v source is required- this can be found on most USB-UART adapters and microcontroller boards (ESP32/8266, Arduino etc). It has been confirmed that the 1.8v source at TP1706 will also work on KT2. KT2, PW2, PW3: Connect a wire from your voltage source to TM401 and reset the device. KT3: Connect a wire from your voltage source to the pad specified in this thread and reset the device. On some devices, it is possible to activate SDP mode without connecting directly to the manufacturing point, making it unnecessary to remove the PCB from the device: KT2: See this thread PW2 & PW3: CR501, right side When SDP mode is active, it will be detected as a SE Blank * device manufactured by Freescale SemiConductor: Code: Bus 003 Device 039: ID 15a2:0063 Freescale Semiconductor, Inc. Code: [ 5574.623011] usb 3-10.1: new high-speed USB device number 39 using xhci_hcd [ 5574.823870] usb 3-10.1: New USB device found, idVendor=15a2, idProduct=0063, bcdDevice= 0.01 [ 5574.823877] usb 3-10.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 5574.823880] usb 3-10.1: Product: SE Blank MEGREZ [ 5574.823883] usb 3-10.1: Manufacturer: Freescale SemiConductor Inc [ 5574.825931] hid-generic 0003:15A2:0063.0012: hiddev0,hidraw0: USB HID v1.10 Device [Freescale SemiConductor Inc SE Blank MEGREZ] on usb-0000:00:14.0-10.1/input0 Loading binaries using imx_usb_loader After SDP mode has been enabled, the device can be accessed from a Linux host using a tool called imx_usb_loader. This tool is packaged and available on most mainstream Linux distributions and can be installed on an Ubuntu system using the command below: Code: sudo apt install imx-usb-loader Loading a U-Boot binary A U-Boot binary can be loaded by executing the command below: Code: sudo imx_usb u-boot.bin This command may give an error similar to the one below depending on your device, imx_usb build and u-boot binary: Code: config file <.//mx6_usb_work.conf> parse .//mx6_usb_work.conf Trying to open device vid=0x15a2 pid=0x0063 Interface 0 claimed HAB security state: development mode (0x56787856) == work item filename ../u-boot.bin load_size 0 bytes load_addr 0x00000000 dcd 1 clear_dcd 0 plug 1 jump_mode 3 jump_addr 0x00000000 == end work item No DCD table loading binary file(../u-boot.bin) to 00980000, skip=0, fsize=1a1e4 type=aa <<<106980, 106980 bytes>>> succeeded (security 0x56787856, status 0x88888888) jumping to 0x00980400 do_command err=-1, last_trans=0 do_command err=-1, last_trans=0 do_command err=-1, last_trans=0 do_command err=-1, last_trans=0 do_command err=-1, last_trans=0 config file <.//mx6_usb_work.conf> parse .//mx6_usb_work.conf Trying to open device vid=0x15a2 pid=0x0063 Interface 0 claimed do_command err=-1, last_trans=0 do_command err=-1, last_trans=0 do_command err=-1, last_trans=0 do_command err=-1, last_trans=0 do_command err=-1, last_trans=0 status failed This error can be safely ignored and is explored in more detail in the "Loading a Linux binary" section. Loading a Linux binary imx_usb_loader is also capable of loading a U-Boot image and Linux kernel (and in theory, a rootfs) at the same time. This requires some additional customisation and configuration, depending on the U-Boot version. Generating a DCD table On Freescale/NXP SoC, peripheral and DRAM initialisation is handled using data structures known as DCD tables. Older versions of U-Boot (e.g uboot-2009.08-lab126) handle DCD tables in a different manner than later versions. Instead of being contained within a separate imximage.cfg file that is integrated into the final U-Boot image after compilation, they are located within the flash_header.S file for that board. On versions that use flash_header.S, the DCD data is structured like so: Code: MXC_DCD_ITEM(2, IOMUXC_BASE_ADDR + 0x5c0, 0x00020000) Each MXC_DCD_ITEM consists of a node ID, a write address to and a value. This needs to be converted to the format below: Code: DATA 4 0x20e05c0 0x00020000 #2 The main difference is that the write address needs to be defined explicitly, which can be achieved by identifying the _BASE_ADDR for that item and adding the offset. Disabling header appending* As DCD initialisation can only be carried out once during each boot cycle, the developer needs to disable the flash header within the defconfig for their device: Code: diff --git a/include/configs/imx60_wario_mfgtool.h b/include/configs/imx60_wario_mfgtool.h index c7c1ad1..41a05b4 100644 --- a/include/configs/imx60_wario_mfgtool.h +++ b/include/configs/imx60_wario_mfgtool.h @@ -29,8 +29,8 @@ #define CONFIG_MX6SL_ARM2 #define CONFIG_WARIO #define CONFIG_WARIO_BASE -#define CONFIG_FLASH_HEADER -#define CONFIG_FLASH_HEADER_OFFSET 0x400 +//#define CONFIG_FLASH_HEADER +//#define CONFIG_FLASH_HEADER_OFFSET 0x400 #define CONFIG_MX6_CLK32 32768 #include <asm/arch/mx6.h> Changing boot command By default, U-Boot will attempt to load a Linux binary from eMMC storage. To load a Linux binary that has been pre-loaded into memory, we need to change the memory location that U-Boot attempts to load from: Code: diff --git a/include/configs/imx60_wario_mfgtool.h b/include/configs/imx60_wario_mfgtool.h index c7c1ad1..ed23fde 100644 --- a/include/configs/imx60_wario_mfgtool.h +++ b/include/configs/imx60_wario_mfgtool.h @@ -218,7 +218,7 @@ #define CONFIG_BISTCMD_MAGIC 0xBC #define CONFIG_EXTRA_ENV_SETTINGS \ - "bootcmd=bootm " MK_STR(CONFIG_MMC_BOOTFLASH_ADDR) "\0" \ + "bootcmd=bootm " MK_STR(CONFIG_LOADADDR) "\0" \ "failbootcmd=panic\0" \ "post_hotkeys=0\0" \ "loglevel=5\0" \ Creating IMX image Once a DCD table in the new format has been created, it needs to be joined to the main U-Boot binary: Code: mkimage -n wario-dcd.cfg -T imximage -e 0x80500000 -d mfgtool.bin u-boot-dcd.imx Creating configuration file To load a Linux binary using imx_usb, the developer will need to create a custom configuration file: Code: # mx6_usb_work_wario.conf KindleTouch2 hid,1024,0x910000,0x70000000,256M,0xF8000000,128K u-boot-dcd.imx:dcd uImage-KT2-stock:load 0x80800000 u-boot-dcd.imx:clear_dcd,load,jump header The configuration file above will carry out the following tasks: The DCD table within u-boot-dcd.imx will be loaded and executed to initialise the device uImage-KT2-stock will be loaded to 0x80800000 The DCD table will be cleared, the entire U-Boot binary will be loaded into memory and the SoC will then jump to the U-Boot execution address If the U-Boot binary has been correctly configured, it will then attempt to load the uImage which has been loaded into memory instead of the uImage contained within the flash storage of the device.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Linux/Windows (dual boot) using same Calibre db?	patrik	Library Management	14	03-27-2022 08:53 PM
External Booting for Kobos (aka boot from external SD card)	pazos	Kobo Developer's Corner	6	02-23-2019 03:39 AM
Booting from a USB pendrive - it is possible?	encol	Kindle Developer's Corner	1	11-08-2016 03:13 PM
[Kindle Touch] Boot over USB HID serial / "USB downloader" mode	eureka	Kindle Developer's Corner	16	02-25-2012 10:21 PM
Dual boot Linux?	Nick_Djinn	enTourage Archive	21	09-23-2010 09:32 PM

10-13-2021, 05:00 PM	#2
nicolasmart Sometimes active. Posts: 132 Karma: 484026 Join Date: Mar 2015 Device: KT2, PW2	Hey again! My KT2 was working gracefully until I let its battery fall down to 0%. I didn't let it fall down that low for quite a while but now it did. When I charged it back up it kicked into DIAGS. I tried doing anything useful - enable usbnet simply did nothing. I could go into fastboot and back but nothing really happened. Tried reflashing kernel with fastboot - didn't help. Yes, I did try fastboot setvar bootmode main. I tried factory resetting. I tried updating to the latest version - pasting the update binary into storage and restarting actually did trigger an update and in the end it said "Update successful!" but once again it kicked into diags. Yes, there was a device_info.xml in diagnostics_logs. I tried setting the bootmode variable to reset and then it completely died. No DIAGS. No screen update. Triggering SDP works but reflashing the only 2 uBoot images i have just triggers a disconnect. Is there any useful way for me to make it reflash the entire thing? Thanks in advance!

08-21-2023, 01:20 PM	#4
nicnic2001 Member Posts: 15 Karma: 10 Join Date: Sep 2016 Device: KT2, Kindle 7th Gen	I do the reset and get to the bit where I have "Product: SE Blank MEGREZ" shown in dmesg. I run imx_usb_loader with uboot fastboot image found here: https://www.mobileread.com/forums/sh...d.php?t=342535 and I get a USB disconnect in dmesg but nothing after this... any ideas?

Advert