The document discusses hacking an embedded Linux system called the Mattel Juicebox, a children's video and MP3 player, by taking advantage of unused debugging interfaces. It covers setting up a toolchain and memory management for systems without an MMU, programming the target system over JTAG, and challenges faced getting uCLinux running on the Juicebox such as modifying its boot process.

1. Hacking embedded
Linux on the cheap
with an example
system
Ed Langley

2. Introduction to the target system
● Mattel Juicebox
– Childrens video and MP3
player
– Only plays video from
OTP ROM cartridges
● Proprietary player and
format
● Low compression
● No OS
– Plays MP3s from MMC
socket cartridge
● Running uCLinux

3. Target system specification
● Samsung S3C440BX micro
controller
– ARM7TDMI core
– 8KB cache/SRAM
– 2 channel UART
– 2 channel DMA
– 1 channel I2C
– 5 channel PWM
– 8 channel 10 bit ADC
– RTC with calendar
– 71 input/output pins
– LCD controller with 1
dedicated DMA channel
● 2MB SDRAM
● 8MB ROM
● Audio: Cirrus Logic CS43L43
● LCD: 2.7 inch color 240x160
● JTAG – pads on PCB left
behind in production boards
● As are serial port Tx/Rx lines

4. Picking your own target system
● Traditional industry method:
– price Vs package size Vs power consumption
– All of above Vs features:
● Speed
● Number of external interrupts
● Supported memory range
● Memory management
● Number of GPIO pins
● Assemblers/compilers/programming languages
supported
● Operating systems supported

5. Picking your own target system
● “On a shoestring” method
– Take what you can get
– Mass produced gadget/appliance
– Contains CPU with architecture supported by Linux
● How much work/research/porting/hacking do you want to do
yourself?
– E.G. Low budget:
● PDAs MP4 video players (from China off Ebay for £20)
● Older games consoles (Dreamcast, PS2, Game Cube)
– E.G. Higher budget:
● Handheld games consoles (PSP, GP2X)
● Set top boxes/routers (Dreambox, Linksys routers)

6. Get your build environment together
● Toolchain
– GCC
– Binutils (ar, as, ld, objdump, objcopy, readelf)
– Debugger
● If the target system has in circuit debugging ability
● GDB
● Interface from GDB to target
– OpenOCD for JTAG, BDM patches for FreeScale MCUs
● Above will have “arch-binaryformat-” prefix
– E.G. arm-elf-gcc, m68k-linux-objdump

7. Test the tool chain
● If system doesn't come with Linux on it already,
best to start with some bare board code
– C run time (assembly code to prepare CPU
configuration and stack to run C code, then call
main())
– Linker script
● Tells code what memory address it will be running from,
so function calls are compiled to JMP instructions to the
correct addresses
– Makefile
● Sets compile/linker commands to use the cross compiling
tool chain, passes linker script to linker

8. Memory management
● Process memory map on typical Linux system
with an MMU:
.text
0x00000000
.data
.bss
Dynamic memory
0x40000000
Stack0xC0000000
Kernel .text
Kernel .data
Kernel .bss
Kernel dynamic memory
Hardware access ranges
Physical memory
Page table
Linear
mapping

9. Memory Management
● Process memory map created by default linker
script, included with tool chain
● When building “Bare board” code, or an
operating system kernel, need to specify
custom linker script
● Script specifies where code is in output file
(ELF) and what address it will be at when MMU
is enabled and page tables configured

10. Lack of memory management
● Low end micro controllers often don't have
memory management units
– Less complexity in silicon
● Cheaper
● Lower power consumption
● Simpler for writing bare board software from
scratch
● Not so easy for running Linux
– No virtual memory addresses
● Processes can't all have the same memory map
● Can't “grow” process address space with sbrk()

11. Lack of memory management
● Solution: uCLinux
– All processes loaded to different physical addresses
● New binary format (FLAT) to handle this
– Different memory allocator
● No brk()/sbrk() system call
● Power of 2
– No fork() system call
● Can't duplicate process memory map because physical
addresses must all be different
● Forces application modification to use vfork()

12. Benefits of no MMU
● Cheaper development tool setup
– Was developing a Linux driver on a v4 Coldfire
board (with MMU) at work
– Tried to debug kernel with m68k-linux-bdm-gdb
– GDB has no concept of virtual addresses
● Written to debug user mode processes
– As soon as GDB tried to read a kernel variable at a
virtual address – Bus error
● Wasn't translating virtual address to physical address
– Never had a problem on previous board (with no
MMU) because virtual address=physical address

13. Benefits of no MMU
● Used one of these:
Lauterbauch Trace32
● Could have used KGDB
– Architecture specific code needs porting

14. Getting the code onto the target
● Plug and prey
– Can take a few goes to get right
– Becomes tiresome trying out changes
● Program the flash/RAM in target
– Requires either:
● Boot loader/monitor preprogrammed into boot ROM
– Not likely on a retail product
● Debug interface hardware and connector on target
– This can be very slow with cheaper debug interface
– Very very slow for programming flash in target

15. Getting code onto the Juicebox
● The S3C44B0X has JTAG interface, connector pads
are present on JB board

16. Joint Test Action Group overview
● Serial data In, Out and Clock lines allow data bits to be
clocked in and out of the Test Access Port (TAP) on
the device
● TMS controls state machine in TAP
● Devices may be chained:

17. Joint Test Action Group overview
● Serial bits clocked in control device pins through a
path of cells known as the Boundary Scan Register:

18. Joint Test Action Group overview
● Toggling TMS signal cycles TAP through a
state machine
● This allows the device pins to be set to the data
clocked in via TDI
● Or to capture the device pin state and clock it
out via TDO
● Control of the pins on the device give control of
the device itself, and RAM/flash connected to
the device
● So JTAG can be used to program memory in
target

19. The JTAG Wiggler
● Macraigor is a company making hardware and
software for embedded development
● They created the standard “Wiggler” design for
connecting PC to target via JTAG:

20. The JTAG Wiggler
● Everyone soon realised the Wiggler is just a
buffer chip on the end of a parallel cable
● Olimex clone:

21. The JTAG Wiggler
● Home made version:

22. It doesn't work- now what?
● Systematic approach
● Start at one end (I.E. Bottom of hardware/ top
of software) and work to the other
● The JTAG connection to the Juicebox wouldn't
work
– Started with the software
● Check permissions – retry as root
● Check parport_pc kernel module not loaded, interferes
with direct port access
– Then moved down to parallel port setup in BIOS

23. Juicebox JTAG not working
● Then checked cable wired correctly – ensure
board schematic drawn with same connector
gender as actually used
● Then checked the schematic:

24. Juicebox JTAG not working
● Result: schematic incorrect
● Amendments made to the website where I
copied it from 5 days later
● Used that schematic because it was in Eagle
CAD format
● Moral of the story
– The less work you do yourself, the more susceptible
you are to mistakes made by others doing the work
for you

25. Getting Linux running on a target
system
● Retail gadgets
– Usually some kind of kludge/hack to get own code
running
– Boot loader often runs checksum calculation over a
range of the code
– Games consoles/handhelds
● Generally require a massive exploit to be found before
any progress is made

26. Getting uCLinux running on the
Juice Box
● Can run home brew code relatively easy
– Can download binary to RAM/flash using Jtager
– Can download ELF using GDB+OpenOCD
● Running code from a fresh boot, not so easy
– Need to steal first 512 bytes from a “Juiceware”
video cartridge and patch with some hex to add a
branch instruction to the custom code

27. Getting uCLinux running on the
Juice Box
● Not actually done this yet
● Have built a “cartridge” to interface some
programmable NAND flash to the S3C44B0X:

28. Getting uCLinux running on the
Juice Box
● Downloading even a minimal Kernel to RAM or
flash over JTAG takes forever
– Have built the kernel to run from RAM as configured
by Emsoft
– Will write this to flash once
● Currently crafting a boot loader to prepare the
CPU, then dump the kernel from flash to RAM
and run it