[Samsung Galaxy Nexus] AdamOutler:
I am doing research for UnBrickable Mod on the Galaxy Nexus. UnBrickable Mod will provide a method of recovering a dead device and guarantee unlocked bootloaders for those with the mod.

I just sorted through the 5,000 page OMAP 4430 processor manual. I believe this OMAP 4430 to be very similar to OMAP 4460 used in the Galaxy Nexus http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.x_Public_TRM_vK.zip

Rebellos and I will require 2 Galaxy Nexus devices to make this technique work. I've done the research and I thoroughly believe UnBrickable Mod on the Galaxy Nexus is possible.

First Galaxy Nexus will be torn down. The processor must be removed and signal endpoints will be documented.

Second Galaxy Nexus will have the modification applied to it. The device will then be shipped to Poland or worked on remotely from Poland by Rebellos.

If this device is anything like previous Galaxy devices which I have worked on, the SysBoot will be locked to OneNAND.. 0b100110. To enable Boot from USB, a hardware modification must be performed to change that to 0b000110. This will allow boot from USB then boot from OneNAND.

Keep in mind this is a Texas Instruments chip...

The first thing that struck me as odd is that OneNAND used to be a Samsung technology.. The next thing was the fact that the SysBoot pins function similarly to the Samsung S5PC110/Exynos xOM pins... on S5PC110, xOM5 must be brough high to enable boot from USB then OneNAND. the OMAP4 allows this same functionality by modifying SysBoot5... I believe Samsung helped develop the OMAP4 chip.

27.4.1 Booting Overview
27.4.1.1 Booting Types
Booting is the process of starting a bootstrap from one of the booting devices.
The ROM code has two functions for booting: Peripheral booting and memory booting.
• In peripheral booting, the ROM code polls a selected communication interface such as UART or USB,
downloads the executable code over the interface, and executes it in internal RAM. Downloaded
software from an external host can be used to program flash memories connected to the device. This
special case of peripheral booting is called preflashing; software downloaded for preflashing is called
the flash loader. The flash loader burns a new client application image in external flash memory. Initial
software is a generic term for bootstrap, downloaded software, and flash loader. After the image is
burnt, a software (warm) reset can be performed.
• In memory booting, the ROM code finds the bootstrap in permanent memories such as flash memory
or memory cards and executes it. This process is normally performed after a cold or warm device
reset.
The ROM code detects whether the device should download software from a peripheral interface (USB or
UART) by using the sys_boot[5:0] pin configuration. This mechanism encompasses initial flashing in
production (external memory is empty) and reflashing in service (external memory is already
programmed).
27.4.1.2 ROM Code Architecture
Figure 27-4 shows the ROM code architecture. It is split into three main layers with a top-down approach:
high-level, drivers, and hardware abstraction layer (HAL). One layer communicates with a lower-level layer
through a unified interface.
• The high-level layer performs the main tasks of the public ROM code: multicore startup, watchdog and
clock configurations, interrupt management, interaction with the power-management IC, and main
booting routine.
• The driver layer implements the logical and communication protocols for any booting device in
accordance with the interface specification.
• The HAL implements the lowest level code for interacting with the hardware infrastructure IPs. End
booting devices are attached to the device I/O pads.
Figure 27-4 shows the three layers with their modules.
5198

With all the similarities between S5PC110, Exynos, and OMAP4, there is still alot left to do.