MobileRead Forums - View Single Post

eureka · 08-15-2012, 04:32 AM

Linux zealots, rejoice (as I do)! There is cross-platform, small command-line utility to load and run binary code or program images over USB Downloader serial protocol. I.e. tool, which is sufficient to replace MfgTool for forced booting into various boot modes.

It's imx_usb_loader, made and open-sourced by nice guys from Boundary Devices. It depends only on libusb and consists of single .c file. Clone repository, make the tool and follow to my guide of it's work.

Note: imx_usb_loader does NOT work on recent Mac OS X, because libusb doesn't support USB HID devices on this OS! Read Kindle 5.3.2 stuck at reboot thread for details.

There is the only (and incomplete) official description of tool, I recommend to read it first.

imx_usb relies on one main configuration file, containing mapping of VID/PID of supported devices to device configuration files, and, obviously, device configuration file(s).

Main configuration file is named imx_usb.conf. This file in repository already contains VID/PID of i.MX508 (Kindle Touch's processor) in USB Downloader mode, however, it's mapped to missed device configuration file mx50_usb_work.conf. So, create missed file with following content:

Code:

KindleTouch
hid,1024,0x70000000,256M,0xF8000000,128K

Format of device configuration file is partially described in existing device configuration files (*_usb_work.conf), so I summarize here these descriptions and my findings after digging into source (at the recent commit 2430416c96).

Empty lines and lines starting from # character are skipped.

First line should contain name of device. It's arbitrary string displayed by tool when appropriate device is found. If line contains spaces, only part before first space is displayed by tool.

Next line should contain device characteristics separated by comma in following sequence:

USB protocol for communicating with device (hid or bulk)
optionally -- string old_header, if device requires old format of program image header (I believe, it's valid only for i.MX51 processors)
maximum packet size in bytes
start address and size of [first] memory area available for writing. Values should be separated by comma. Values begiining from 0x are recognized as hex numbers. Size value could be suffixed with one of k/K/m/M/g/G characters (it's multipliers standing for kilo/mega/giga)
optionally -- start address and size of next memory area(s) available for writing

As you've seen, Kindle Touch in USB downloader mode supports HID protocol with maximum packet size of 1024 bytes. I've set two memory areas as available for writing: first (with size of 256M) is DRAM area, second (with size of 128K) -- is OCRAM area. I've took these values from Reference Manual: I hope, I wasn't wrong in interpretation of table with memory map.

Every next [meaningful] line is optional. It should contain path to file to operate with, then colon, then directives, separated by comma. Directives are:

dcd -- load device configuration data (DCD) from program image into device
clear_dcd -- set DCD address field in IVT header of program image to NULL (0)
plug -- without jump uses header, but clears plugin flag to stop after plugin execution (??? / description copied straight from example configuration file, even after looking into sources, it's hard to say something more clear)
load N -- load file to device at address N (values beginning from 0x are recognized as hexidecimal numbers)
jump N -- jump to address N and start executing (values beginning from 0x are recognized as hexadecimal numbers)
jump header -- use load address and data length from first found IVT header of program image and exit with error if header wasn't found. Plugin flag in Boot Data Structure will be cleared. After loading, jump to load address.
jump header2 -- use load address and data length from second found IVT header of program image and exit with error if header wasn't found. Plugin flag in Boot Data Structure will be cleared. After loading, jump to load address. (Note: though this directive is recognized by tool as valid, I didn't found any specific code for processing it's case.)

So, these optional lines pointed to any files could be used for automating of loading/executing specific binary code or program images. Look into stock *_usb_work.conf files for examples.

(For definitions of "program image", "DCD", "IVT", "Boot Data Structure", refer to i.MX50 Reference Manual.)

Anyway, if path to some file is given as command line argument, these optional lines are skipped (if they were found) and tool loads given file with automatical applying of following directives: dcd, plug, jump header.

U-Boot built from Amazon sources is the program image, so it is suited for loading through passing of command-line argument.

TL;DR:

clone repository
build tool
create file mx50_usb_work.conf with content from code block somewhere upper in text
connect KT in USB downloader mode to computer
run tool with passing path to U-Boot binary as command-line argument

I've succesfuly booted into diagnostic mode through loading of specific U-Boot with this tool.

08-15-2012, 04:32 AM	#225
eureka but forgot what it's like Posts: 741 Karma: 2345678 Join Date: Dec 2011 Location: north (by northwest) Device: Kindle Touch	Linux zealots, rejoice (as I do)! There is cross-platform, small command-line utility to load and run binary code or program images over USB Downloader serial protocol. I.e. tool, which is sufficient to replace MfgTool for forced booting into various boot modes. It's imx_usb_loader, made and open-sourced by nice guys from Boundary Devices. It depends only on libusb and consists of single .c file. Clone repository, make the tool and follow to my guide of it's work. Note: imx_usb_loader does NOT work on recent Mac OS X, because libusb doesn't support USB HID devices on this OS! Read Kindle 5.3.2 stuck at reboot thread for details. There is the only (and incomplete) official description of tool, I recommend to read it first. imx_usb relies on one main configuration file, containing mapping of VID/PID of supported devices to device configuration files, and, obviously, device configuration file(s). Main configuration file is named imx_usb.conf. This file in repository already contains VID/PID of i.MX508 (Kindle Touch's processor) in USB Downloader mode, however, it's mapped to missed device configuration file mx50_usb_work.conf. So, create missed file with following content: Code: KindleTouch hid,1024,0x70000000,256M,0xF8000000,128K Format of device configuration file is partially described in existing device configuration files (_usb_work.conf), so I summarize here these descriptions and my findings after digging into source (at the recent commit 2430416c96). Empty lines and lines starting from # character are skipped. First line should contain name of device. It's arbitrary string displayed by tool when appropriate device is found. If line contains spaces, only part before first space is displayed by tool. Next line should contain device characteristics separated by comma in following sequence: USB protocol for communicating with device (hid* or bulk) optionally -- string old_header, if device requires old format of program image header (I believe, it's valid only for i.MX51 processors) maximum packet size in bytes start address and size of [first] memory area available for writing. Values should be separated by comma. Values begiining from 0x are recognized as hex numbers. Size value could be suffixed with one of k/K/m/M/g/G characters (it's multipliers standing for kilo/mega/giga) optionally -- start address and size of next memory area(s) available for writing As you've seen, Kindle Touch in USB downloader mode supports HID protocol with maximum packet size of 1024 bytes. I've set two memory areas as available for writing: first (with size of 256M) is DRAM area, second (with size of 128K) -- is OCRAM area. I've took these values from Reference Manual: I hope, I wasn't wrong in interpretation of table with memory map. Every next [meaningful] line is optional. It should contain path to file to operate with, then colon, then directives, separated by comma. Directives are: dcd -- load device configuration data (DCD) from program image into device clear_dcd -- set DCD address field in IVT header of program image to NULL (0) plug -- without jump uses header, but clears plugin flag to stop after plugin execution (??? / description copied straight from example configuration file, even after looking into sources, it's hard to say something more clear) load N -- load file to device at address N (values beginning from 0x are recognized as hexidecimal numbers) jump N -- jump to address N and start executing (values beginning from 0x are recognized as hexadecimal numbers) jump header -- use load address and data length from first found IVT header of program image and exit with error if header wasn't found. Plugin flag in Boot Data Structure will be cleared. After loading, jump to load address. jump header2 -- use load address and data length from second found IVT header of program image and exit with error if header wasn't found. Plugin flag in Boot Data Structure will be cleared. After loading, jump to load address. (Note: though this directive is recognized by tool as valid, I didn't found any specific code for processing it's case.) So, these optional lines pointed to any files could be used for automating of loading/executing specific binary code or program images. Look into stock _usb_work.conf files for examples. (For definitions of "program image", "DCD", "IVT", "Boot Data Structure", refer to i.MX50 Reference Manual.) Anyway, if path to some file is given as command line argument, these optional lines are skipped (if they were found) and tool loads given file with automatical applying of following directives: dcd, plug, jump header. U-Boot built from Amazon sources is the program image, so it is suited for loading through passing of command-line argument. TL;DR: clone repository build tool create file mx50_usb_work.conf* with content from code block somewhere upper in text connect KT in USB downloader mode to computer run tool with passing path to U-Boot binary as command-line argument I've succesfuly booted into diagnostic mode through loading of specific U-Boot with this tool. Last edited by eureka; 01-12-2013 at 11:18 AM. Reason: imx_usb_loader doesn't work on MacOS X