www.writefayewrite.com/images/pdfs/DatasheetII.pdf
Qualcomm’s operating system is called Advanced Mobile Subscriber
Software (AMSS), also referred to as Dual-
Mode Subscriber Station
(DMSS). The OS allocates resources for up to 69 concurrent tasks, includ
-
ing hardware management for USB, USIM, GPS, etc., and contains proto
-
col stacks at each layer (GSM, L1, L2, RR, MM, etc.). The primary processor
boots first, ARMx, executing the primary boot loader (PBL) from on-
board
ROM at 0xFFFF0000. The mobile station modem (MSM) platform design
couples CDMA (code-
division multiple access) and UMTS (Universal
Mobile Telecommunications System) modem chipsets. After hardware
initialization, the PBL reads the device boot loader (DBL) from the first
partition of flash memory. DBL is a function of Qualcomm’s SecureBoot,
which uses cryptography to guarantee there has not been interference with
the boot loader images. DBL then configures a dedicated cryptographic
co-
processor, Cryptographic Look-
aside Processor (CLP), and other hard
-
ware to load and execute the secondary boot loader (SBL) from flash mem
-
ory on an external bus interface (2) from a dedicated partition (3).
The SBL is loaded into memory, which is an internal memory loca
-
tion, on the MSM internal memory, the package-
on-
package RAM. This
is the ARMx Monitor (AMON), where x signifies the primary processor
model number, and it provides an Extensible Firmware Interface (EFI)
environment for controlling the boot process. After more hardware
configuration takes place, including USB and universal asynchronous
receiving/
transmitting (for potential remote console connections to the
monitor), it loads the Applications Processor Secondary Boot Loader
(
hboot
) on the ARMxx applications processor from a dedicated parti
-
tion (14) into both virtual and physical memory.
REX and AMSS are loaded and executed from another dedicated par
-
tition (4). REX, running on Security Domain 0, is responsible for load
-
ing firmware into the ancillary micro-
controller, digital signal processor.
and voice processor and initializing them. The image includes the REX-
embedded micro-
kernel, such as L4A Pistachio, and Iguana operat
-
ing system combination, with extensive Qualcomm modifications and
extensions. Once ARMxx boots, REX unloads/
disconnects its eMMC
(multimedia card) driver and relies on remote procedure calls (RPCs) via
shared memory to the ARMxx application processor to read and write
the eMMC. Subsequently, the ARMx REX executes the Advanced Mobile
Subscriber Software (AMSS), running on Security Domain 1.
48
◾
Lauren Collins
Figure 3.5 illustrates the flow for the system boot sequence.
Core REX tasks are
•
DIAG
: Provides the diagnostic interface.
•
CM
: Call manager task.
•
DS
: Data services task (unified data gathering task for all protocol layers).
•
DOG
: Watchdog (constantly checks whether tasks are alive).
•
DPC
: Routes adjacent point code (APC) across tasks.
•
MAIN
: Launches all system tasks, handles timer events.
•
PS
: Packet-
switched services (network stacks at upper layers, TCP/
IP,
PPP, etc.).
•
SLEEP
: Idle task
seems the kyocera rise c5155 abd hydro c5170
what you need can be found in /proc/config.gz
they have a few different options for the crypt keys think its based off hwmac really need a jtag for this but it creates a temp ram disk and has a cmdline in bootloader. init=/sbi/init /dev/ram initrd 0x11000000 pretty much need to dump the ram it loads a bunch of virtual machines on top of everything.more or less it uses the emulated environment to shield itself, some commands get passed to the real system. probably will have to work on getting something setup with that boot buddy thing to dump the file during boot. i wonder how difficult it would be to implement
https://github.com/qemu/u-boot sounds like what is needed they probably use something similar for the bootloader but the feature here is to do a ram dump and then force u-boot to relocate the space CONFIG_RAMBOOT and CONFIG_NFSBOOT
The value of these goes into the environment as
"ramboot" and "nfsboot" respectively, and can be used
as a convenience, when switching between booting from
RAM and NFS.
Protected RAM:
CONFIG_PRAM
Define this variable to enable the reservation of
"protected RAM", i. e. RAM which is not overwritten
by U-Boot. Define CONFIG_PRAM to hold the number of
kB you want to reserve for pRAM. You can overwrite
this default value by defining an environment
variable "pram" to the number of kB you want to
reserve. Note that the board info structure will
still show the full amount of RAM. If pRAM is
reserved, a new environment variable "mem" will
automatically be defined to hold the amount of
remaining RAM in a form that can be passed as boot
argument to Linux, for instance like that:
setenv bootargs ... mem=\${mem}
saveenv
This way you can tell Linux not to use this memory,
either, which results in a memory region that will
not be affected by reboots.
*WARNING* If your board configuration uses automatic
detection of the RAM size, you must make sure that
this memory test is non-destructive. So far, the
following board configurations are known to be
"pRAM-clean":
IVMS8, IVML24, SPD8xx, TQM8xxL,
HERMES, IP860, RPXlite, LWMON,
FLAGADM, TQM8260
- Access to physical memory region (> 4GB)
Some basic support is provided for operations on memory not
normally accessible to U-Boot - e.g. some architectures
support access to more than 4GB of memory on 32-bit
machines using physical address extension or similar.
Define CONFIG_PHYSMEM to access this basic support, which
currently only supports clearing the memory.
