J's BS

Papers and Patents about LTO drives

2026-10-10T00:00:00+02:00

Publications in scientific and engineering journals

IBM Research wrote a nice article about the technology behind LTO drives and published it OA/CC-BY 4.0:

Magnetic Tape Storage Technology MARK A. LANTZ et al. ACM Trans. Storage, Vol. 21, No. 1, Article 6. January 2025.

Frame Synchronization for PPM-encoded Longitudinal Position Words in Magnetic Tape Storage, Giovanni Cherubini, Roy D. Cideciyan, Evangelos Eleftheriou, and Jens Jelitto IEEE "GLOBECOM" 2009 proceedings.

Patents

Useful Links about LTO drives

2026-10-10T00:00:00+02:00

My browser needs to have fewer tabs open, so I'm putting them here.

Usage

Introduction into LTO on Linux LTO Tape data storage for Linux nerds

Using tar for its original purpose Linux Tape Backup With mt And tar Command Howto

Library (de-) integration

IBM library tape drive to standalone reconfiguration (HP-style drives sense a connected library automatically) How to turn an IBM Drive into automatic standalone mode

MSL2024, drive ADI/LDI connector, fans & noise management Adventures in LTO Tape Drives

Service password for Library & OOBMGMT Out-of-Band management MSL2024/4048/SL24/SL48

(Dis-) Assembly

Repairing a tape backup LTO 2 unit: HP Ultrium 448 with broken tape

Disassembling and cleaning an LTO tape drive head (HP mechanism)

Disassembling an HP Ultrium 460 tape drive head

Full teardown: IBM LTO-4 ленточный привод: разбираю на атомы.

Tape formats

Tape encryption and compression formats/algorithms, raw reading The secrets of LTO tape

If you buy used tapes anf old equipment, sometimes there are free tapes with free data Recovering NTBackup Tapes

Tools

Unknown quality here

Official documentation

IBM LTO7 HH drive, useful but not massively so Setup, Operator, and Service Guide Machine Type 3580 Model H7S

Dell TL2000/4000 manual with pictures and useful info about library components Dell PowerVault TL2000 Tape Library and TL4000 Tape Library User's Guid

mt documentation from RHEL 10 Chapter 15. Managing tape devices

HPE-stlye firmware update package

2026-10-09T00:00:00+02:00

HP header

LTO3

NEC/Renesas V850

LTO4

32bit LE ARM (arm v5t)

LTO5

32bit LE ARM Cortex

MG Electronics / Clack Corp 15V power supply

2026-10-04T00:00:00+02:00

The MG Electronics SL-150B005-EU, also sold as Clack Corporation V3286EU-06, is a 15V DC power supply with a long cable and a 4-pin 0.1in plug that is uesd to supply the Clack WS 1 control valve for water softening and filtration devices.

The WS1 has a full bridge rectifier right after the power plug, so it should not be picky about AC, DC or polarity, here is the power plug pinout anyway:

Pin	Function
1	+15 V
2	shorted to pin 3
3	shorted to pin 2
4	GND

The power supply is well constructed, enought isolation between primary and secondary side, well isolated transformer, correct capacitors, etc

Nevertheless, the output rectification Schottky diode, type SS310FL (D7, lower left corner) had failed and was replaced with a SK310A (100V, 3A) Schottky diode.

The case is glued, but has alignment pins in the corners. If they are not sheared off when cracking the case, the unit is easy to glue back together.

IBM LTO5 firmware

2026-09-30T00:00:00+02:00

Update file sectioning

There is a global header and 3 discernable sections, the header is 0x30 bytes, the chunks are 0x30 - 0x2002f, 0x20030 - 0x4002f and 0x40030 - EOF @ 0x4c112.

Section 2 looks like 2 sections, as the exact second half is pretty empty and contains a series chained headers across most of the mostly-zero part.

Lots of header entries are duplicate, so there may be an A/B redundancy scheme going on.

0x30030 - 0x4002f looks like its own section with its own encoding scheme, but it is included in the header of section 2.

Section 3 has two flash to memory mapping tables at 0x200 and 0xA10, including duplicate reset vector descriptions and copyright notices.

summary

Section 1 contains a bootloader that does a little bit of setup and then jumps to the next stage.

Section 2 is more elaborate, TBD.

Section 3 is the "application" section, lots of code, complicated memory map and debug output strings for tape drive setup and debugging. Most of its subsections are LZW-compressed.

Memory/flash maps

mem map

offset	size	description
100 0000		a peripheral ?
FFC 0000		32MiB boot flash?
1000 0000	400 0000	64 MiB SDRAM
a000 0000		OPB bus controller ?
ef00 0000		peripherals ?
ef60 0300	8	N16550 serial controller
fe00 0000	200 0000	32 MiB NOR flash, maype upper part of 0xf800 128MiB NOR like later
ffff fffc	4	PPC reset vector

flash map from application section header

There are two flash maps, the uncompressed image stored at 0xFE00_0000, where stored size and offsets match memory target size, and the compressed image stored at 0xFE80_0000 where the stored size is smaller than the target memory size.

The headers for both are very similar, only stored addresses and sizes differ besides a small extra block of extra info about stored-only sections in the compressed image header.

This is the compresed flash map:

file offset	stored size	mem offset	mem size	description
fe80 0000	800			header
fe80 0800	32 1F25	1020 0000	42 A63C
feb2 2730	8 1AEF	1070 0000	D 7AC4
feba 4220	4 146A	1080 0000	8 CC58
febe 5690	2 D097	1014 0000	3 AA74
fec1 2730	1FF8	100 8000	3744
fec1 4730	229	100 0000	298	system configuration block
fec1 4960	A BE90
fecc 07f0	110
fe7f f7f0
		1088 D000	12E2 CF44
		100 0400	100 39E0
		12F0 0000	137B 4EB0
		100 3C00	100 3C20

memory map from TLB setup

device end	device start
fe00 03c0	fe00 0005
ff00 03c0	ff00 0005
7000 0040	7000 0105
a000 03c0	a000 0105
b000 03c0	b000 0105
ef60 0340	ef60 0105
100 0140	100 0104
100 4140	100 4104
100 8140	100 8104
ffc 0240	ffc 0204
1014 0240	1014 0000

ram start	ram end
1020 0000	1070 0000
1070 0000	1080 0000
1080 0000	12e4 0000
12f0 0000	1380 0000
1380 0000	13ec 0000
13ec 0000	13f0 0000

1000 0000	1000 4000
1000 4000	1000 8000
1000 8000	1000 c000
1000 c000	1001 0000
1001 0000	1001 c000
1001 c000	1002 0000
1002 0000	1014 0000

device end	device start
4000 03c0	4000 0105
100 09b0	100 09b4

LTO firmware across the ages

2026-09-24T00:00:00+02:00

LTO5

This one has a completely different firmware image format from its successors, it is not based on embedded Linux yet, but it is an embedded PowerPC processor with a similar memory layout.

There are 2 distinct firmware sections like the later fcod/pcod and a large application section with LZW compressed data.

LTO6-9 - 4 Generations of similar firmware

As a long-lived business product, IBM's LTO drive firmware has not changed much since LTO6 drives came out, LTO10 marks the first firmware image format change. This is despite substantial changes to the tape, tape heads and storage interfaces which Wikipedia summarizes nicely.

SAS drive firmwares are consistently a little smaller (50 kiB) than their FC counterparts due to their smaller kernel and initrd.

The memory layout as specified in the firmware update header is identical from LTO6 to LTO9, only the sizes of some sections change slightly, mostly the Linux image vmli and its initrd ramf which grow slightly with each new generation.

For the LTO7 generation, it seems like HPE gave up on their own tape machanism and their firmare updates are now a wrapper around an IBM firmware image.

LTO10 - big changes in hardware, small changes in firmware

LTO10 (aka LTOA) moves the memory layout around, instead of starting at 0x10000000 with kmem, firmware now starts at 0x90000000, though section order stays largely the same and relative offsets change very little.

It also introduces a new 0x180-byte section called csm at 0x9FFC0000 and the ocmd section (presumably flash control) moves from 0x06000000 to 0xD0000000 and shrinks from 0x104 to 0x4.

The global and pcod header magic string is changed to IBMTpDrA to prevent issues when updating.

These changes are necessitated by IBM switching from their embedded PowerPC platform to a Synopsys ARCv2 HS38 processor, which is a synthesizable 32-bit RISC core design now owned by MIPS owned by Global Foundries; peripherals are expected to be mostly from the Synopsys DesignWare catalog. For a complete change of processor architecture and peripherals, surprisingly little has changed in the firmware image.

IBM LTO8 memory map

2026-09-23T00:00:00+02:00

Combined mmap

Phys addr	size	name
0600 0000	104	fcod ocmd
0600 0000	100	pcod ocmb
0600 0100	4	pcod ocmd
07FD 0000	4	pcod ocmt
1000 0000	A0 0000	fcod kmem
10A0 0000	4820	fcod
10B0 0000	19 B544	vmli
10D0 0000	4A 1678	ramf
1120 0000	2 0000	pcod
1122 0000	1230	fcod text
1130 0000	744	fcod roda
1130 0744	1E1C	fcod vmal
1140 0000	4	fcod data
1150 0000	61 001C	fcod bss
11A0 0000	3250	pcod text
11A1 0000	F5C	pcod roda
11A2 0000	4	pcod data
11A3 0000	2010	pcod bss
11C0 0000	1 0000	fcod stac
a000 0000	6000 0000	linux opb
a000 0600	100	linux irq ctrl
ef60 0300	8	linux serial
ef60 0790	c	linux rgmii
ef60 0800	70	linux ethernet
F800 0000	800 0000	linux flash
FFFE 0000	2DD0	pcod (pcod)
FFFF FFFC	4	pcod rese

fcod mmap

Phys addr	size	name
0600 0000	104	ocmd
1000 0000	A0 0000	kmem
10A0 0000	4820	fcod
10B0 0000	19 B544	vmli
10D0 0000	4A 1678	ramf
1120 0000	2 0000	pcod
1122 0000	1230	text
1130 0000	744	roda
1130 0744	1E1C	vmal
1140 0000	4	data
1150 0000	61 001C	bss
11C0 0000	1 0000	stac
ef60 0300	8	serial

pcod mmap

Phys addr	size	name
0600 0000	100	ocmb
0600 0100	4	ocmd
07FD 0000	4	ocmt
1000 0000	A0 0000	fcod kmem
10A0 0000	4820	fcod
10B0 0000	19 B544	vmli
10D0 0000	4A 1678	ramf
1120 0000	2 0000	pcod
1122 0000	1230	fcod text
1130 0000	744	fcod roda
1130 0744	1E1C	fcod vmal
1140 0000	4	fcod data
1150 0000	61 001C	fcod bss
11A0 0000	3250	text
11A1 0000	F5C	roda
11A2 0000	4	data
11A3 0000	2010	bss
ef60 0300	8	serial
FFFE 0000	2DD0	pcod
FFFF FFFC	4	pcod rese

Investigating IBM LTO tape drive firmware

2026-09-20T00:00:00+02:00

Hardware

Processor is identified as a 400MHz IBM PowerPC 405S, 32-bit big-endian by the embedded devicetree file.

132MiB of physical memory is mapped at 0x10000000.

There is a PLB running at 200MHz hosting a DMA engine and the OPB.

The OPB runs at 100MHz and claims any addresses > 0xA0000000 and the following devices live in this space:

pirq interrupt controller @ 0xA0000600
n16550 serial controller @ 0xEF600300
axon ethernet rgmii @ 0xEF600790
axon ethernet controller @ 0xEF600800
128MiB CFI NOR flash @ 0xF8000000, partitioned into 96MiB nvdfs and 32MiB bootimg

There is evidence of more unknown peripherals:

0xA0000F90
0xA0001000
0xA0010000
0xA0800000 maybe DDR SDRAM PHY
0xD0000000
0xEF640000

General image

Tape firmware container with "IBMTpDrv" magic.

Header format in 4 byte fields unless noted otherwise:

jump_instruction / image_size / checksum? / fw_version (4 char) / 0 / 0 / product_id (EBCDIC, 8 bytes) / IBMTpDrv magic ( 8 bytes) / ?? / ?? / ?? / ?? / directory_offset / directory_size / payload_start / ?? / ?? / ??

Section directory with variable number of slots (default 16 slots), each 32-byte, usually at offset 0x80.

Entry format in 4-byte fields:

name / attributes / file_offset / stored_size / memory_address / memory_size / ?? (0) / ?? (0)

file_offset is counted from start of the file

Typical sections are fcod/text/roda/vmal/vmli/ramf/pcod/data/kmem/bss/stac/ocmd.

fcod starts at offset 0 and contains the complete file header

Trailers, TLV coded, are stored after each stored section and not included in the directory. They appear as (usually 20 byte) gaps in the offsets+size covered by the directory.

Example: [80 00 00 04 VV VV VV VV][40 00 00 04 VV VV VV VV][00 00 00 00].

Schema is [TT 00 LL LL VV * length], LL LL is masked with 1F FF.

not chained, both checksums only check the section they are placed after
tag 0x80 = BE u32 sum mod 2^32
tag 0x40 = GF(2^8) table transform T[i]=[i·38 i·CF i·38 i] mod 0x11D, init 0

There is a global trailer at the end of the file backwards TLV scheme starting from end of file, mirror of the section trailer scheme, with chained coverage.

New tags in global trailer:

0x20/0x10 : 256-byte objects, probably crypto signatures like RSA2048
F0/F1 32-byte slots, at end, tombstone, all zeroes

Validator functions in code:

ImageTableValidate (per-section, exact size match)
ImageFileValidate (global backward walk, declared±0x80, required mask 0x50000000 = {0x40, 0x10}, sentinel 0x60000).

Two validator copies: fcod (10a026xx) file-level, pcod (112048xx) section-level clone. GF(2^8) table @ 11A10000 = in BSS, used by pcod, runtime-initialized.

fcod @ 0x00 → 0x10A00000 ~18kb

Startup code, includes global file header

Functions right at the start of section set up CPU/TLB/memory map, after that there are functions concerned with firmware update, e.g. checking the firmware image, erasing flash, writing flash, NOR flash unlock and communication, serial logging, flash verify.

The fcod section looks very minimal and self-contained and contains a DTB right at the end:

PowerPC 405S, ibm,jag5 / ibm,ltox
132MB RAM @ 0x10000000
flash 0xF8000000 128MB
nvdfs 96MB + bootimg 32MB partitions

text @ 0x4834 → 0x11220000 ~4.5kb

FCOD functions for booting the Linux kernel, like checking ELF images, initrd, devicetree and doing CPU and memory setup.

roda @ 0x5A78 → 0x11300000 ~2kb

Lots of strings for fcod that make it easy to identify firmware update code and kernel bootloader.

vmal @ 0x61D0 → 0x11300744 ~7.5kb

Loaded directly after roda. All zeroes.

vmli @ 0x8000 → 10B00000 ~1.6MB

last 4 bytes are a BE32 size in bytes
Entry stub b + 0x250 / 0x280
magic LTOxMCP @ +4
GOT @ pcod +0xA5B0 (in main image terms pcod file off 0x644BE4 + 0xA5B0 = 0x64F194..0x64F1E4), self-referential r30=PC+0x125B0.
Bootloader with minimal DTB and gzipped Linux kernel
no standard uImage, zImage, etc.
Supposedly standard linker layout for embedded PPC Linux without bootloader?

ramf @ 0x1A3558 → 10D00000 ~4.6MB initrd.

last 4 bytes are BE32 size in bytes
XZ-compressed CPIO archive (initrd)
reported as defective by xzcat due to length bytes at the end
minimalist environment, /bin is busybox, sysv-like init with shell scripts, network config with shell scripts
based on RHEL7? glibc 2.17
/drv contains tape drive operating software
/nvd is the "nvdfs" partition from earlier, formatted with ubifs, contains non-volatile files
dropbear is part of debug build, missing form production

Tape drive software

/drv/dcode.exe is a BE32 PPC ELF executable, operates most of the drive
/drv/scode.bin is loaded by dcode.exe
scode.bin contains lots of drive debug and manufacturing diagnostics code with lots of strrings that indicate function

pcod @ 0x00644BE4 → 0x11200000 exactly 128kb

Nested IBMTpDrv container (dir @ 0x50, 16 32-byte slots, magic is the same)

Sections :

text @ 0x2DE4 → 11A00000,
roda @ 0x6048 → 11A10000,
data @ 0x6FB8 → 11A20000,
bss → 11A30000 +0x201000,
rese @ 0x0001FFFC→ 0xFFFFFFFC
ocmt → 0x07FD0000
ocmb → 0x06000000
comm → 0x00000000
ocmd → 0x06000000 (flash controller offset?).

Functionality:

Adler-32 (zlib NMAX 5552, unroll 16) found in pcod, likely inflate consumer.
Flash writing and serial output

data @ 0x00664BF8 → 0x11400000 4 bytes

4 bytes of zeroes, last section warked as stored with file contents

memory only sections

(Linux) kernel memory, BSS section, Stack section, and ocmd may be the flash controller registers.

kmem → 0x10000000 size 0x00A00000
bss → 0x11500000 size 0x0061001C
stac → 0x11C00000 size 0x00010000
ocmd → 0x06000000 size 0x00000104

TODO

IBM 3592 Hardware Reference / Maintenance Information 3592 SCSI Reference documents a lot of vendor-unique behavior, log pages, and diagnostic commands.

IBM Redbooks on TS1150 / TS4500

ITDT (IBM Tape Diagnostic Tool) check out drive dumps

IBM patents on tape servo, LTM/DSP, and formatter design — IBM patents their tape work heavily and the figures are often block diagrams of the real silicon.

FCC/teardown photos