BREC

Note: This article is currently considered for a major rewrite by User:Amyk. Please do not trust the information on this page too much.

The 2nd-stage bootloader

BREC stands for BootRECord; this small 16kB sized bootcode (Z80 instruction set) is held in the NAND flash chip at the first page (the boot record of the flash). The flash also contains a second image (mirror) of this bootloader, following the first one some pages later.

The BREC gets flashed with the content from the flash-type-related BRECxxxx.BIN (located inside the AFI file) during each firmware update. Which BREC version to use gets determined by the update routine.

Some versions (mostly with black'n'white displays) include code to control the display which brings up the (in)famous hour-glass logo, also included inside the BREC file. The BREC bootcodes one and only action, beside displaying the funny hourglass logo, is to detect (position and size) of each NAND flash chip and search for a valid firmware image. Once found it loads and executes the "SYSCFG.SYS" file from this image. After this action is finished, the bootloader is done and the firmware application takes over the device.

Execution flow chart

• 1st-stage bootloader detects flash type and loads BREC into ZRAM1 or IPMM (v9)
• 1st-stage bootloader does a checksum on the BREC. If it passes, it then executes it (jp 0x0000), otherwise it enters ADFU Recovery Mode.
• BREC initializes the display controller and shows the hourglass image.
• (?) compares the boot record source image with the 4 mirror image, and if necessary repairs the source image with the mirror, and vice-versa TODO
• (?) scans the blocks in the flash and builds block mapping tables for FTL
• (?) checksums the directory block and files of the first firmware image
• (?) checksums the directory block and files of the second firmware image
• (?) if either is found to be corrupt, attempts to repair by replacing the corrupt copy with the other good copy. if neither is valid, returns to BROM's ADFU.
• locates and loads the system configuration module (SYSCFG.SYS) file from the firmware image of the first flash to address 0x600.
• passes active execution to the system configuration module

The Checksum

The BREC and BROM check the validity of the BREC in two stages.

• 1. Boot signature. The 16-bit little-endian word at offset 3fbc must have the value 0x55aa.

• 2. Checksum. The result obtained by taking the BREC two bytes at a time in little-endian order and summing the resulting 16-bit words (modulo 65536) from 0000 to 3fbd (inclusive) must equal the 16-bit little-endian word at offset 3fbe.

This is the subroutine that performs the calculation in the v9 BROM:

; check integrity of BREC 
; return: 0 = OK 
X0981: in a,(4eh) 
 or 8 
 out (4eh),a 
 ld a,0f1h ; map in IPMM where first 16K of flash was read into 
 out (5),a 
 ld hl,(X7fbc) ; offset 3fbc in BREC 
 ld de,X55aa 
 xor a 
 sbc hl,de  ; check boot signature (55aa) 
 ld a,l 
 or h 
 ret nz 
 ld hl,X0000 ; initialize sum to 0 
 ld bc,X7fbe 
X099d: dec bc 
 ld a,(bc)  ; high 
 ld d,a 
 dec bc 
 ld a,(bc)  ; low 
 ld e,a 
 add hl,de   ; do word sum 
 ld a,c 
 cp 0 
 jr nz,X099d 
 ld a,b 
 cp 40h     ; finished? 
 jr nz,X099d 
 ld de,(X7fbe) ; checksum word (must equal sum) 
 xor a 
 sbc hl,de 
 ld a,l 
 or h 
 ret 

The Hourglass

At address 3000 in the BREC is the subroutine which displays the hourglass image. This code is display-controller-dependent; some variants use a compact "virtual machine" and bytecodes to execute the init sequence, while others consist of a long sequence of CALLs, INs, and OUTs. For example, it has been found that the SSD178x, and other S1D15xx-derived controllers use the virtual machine, while others use standard code.

The hourglass image itself does not vary much between players with the same display color depth; it is displayed by setting the entire screen to one color, then writing only the pixels that comprise the icon itself, since storing the whole screen image would take far too much space (for example, a 132x132 16-bit image is already over 32KB, more than the BREC itself).

A typical image is 20x36 and 16-bit depth (2 bytes per pixel).

BREC files

Each BRECFxxx.BIN is written for a different type of NAND flash memory, the onboard memory block. Other differences may reside on the display driver, used to show the hourglass on boot time. There are several different types around, and currently their differences are still an area of active research:

• BRECs for 128 and 256KB-blocksize flash:
  • BRECF28A.BIN
  • BRECF289.BIN
  • BRECF288.BIN
  • BRECF287.BIN
  • BRECF286.BIN
  • BRECF285.BIN
  • BRECF284.BIN
• BRECs for 64KB-blocksize flash:
  • BRECF648.BIN
  • BRECF644.BIN
  • BRECF641.BIN
• BRECs for 32KB-blocksize flash:
  • BRECF321.BIN

Each firmware image contains the correct BRECFxxx.BIN. During recovery-mode flashing, the update tool sends some code to detect the flash type, after this step it sends only a firmware containing the specific files, support for other flashs would not be included.

BREC Replacement

Phire has coded a replacement BREC for v9 players. You can check more info on the his mail list post.

Related Pages

• ZRAM1, where the BREC is executed at run-time
• NAND, the physical memory holding the 2nd-stage bootloader
• BROM, the physical memory holding the 1st-stage bootloader
• BLOD, the 1st-stage bootloader code
• TROM, ??

Source code

PulkoMandy disassembled BRECF285.BIN from a v9 device. You can have a look at the sourcecode here