1 add code
\modem_proc\build\ms\flash_type_8X25.cfg
FlashType: FLASH_KML5U000HM_B505
EBI1_ID: O
EBI2_ID: S
Description: samsung 4gB + 8gb JEDEC eMCP class 100 tlc
2 copy file to
\modem_proc\build\ms\flash_8X25\custFLASH_KML5U000HM_B505.h
\modem_proc\build\ms\flash_8X25\targetFLASH_KML5U000HM_B505.h
3 add defined(FLASH_KML5U000HM_B505)
\modem_proc\core\systemdrivers\clkregim\src\proc\mpss\clkrgm_mpss_sdram_7627.c
#if ...|| defined(FLASH_KML5U000HM_B505)
#define CLKRGM_SDRAM_EBI_TRFC 1200
#if ...|| defined(FLASH_KML5U000HM_B505)
#define CLKRGM_SDRAM_EBI_TCKE_TCK 2
4 copy file to
\modem_proc\core\boot\secboot\cfg_data\7627\ebi1\ebi1_kml5u000hm_b505.cfg
5 copy and modify like SSKxLYM_FLASH_xxx.CMD
change USES_FLASH_xxx=yes to USES_FLASH_KML5U000HM_B505=yes
6 add code
\modem_proc\build\ms\boot_targets_nonsec.min
#samsung 4gB + 8gb JEDEC eMCP class 100 tlc
ifeq ($(USES_FLASH_KML5U000HM_B505), yes)
COPY_CFG_DATA += cp -Rf $(CFG_DATA_TARGET)/ebi1/ebi1_kml5u000hm_b505.cfg $(CFG_DATA)/ebi1/ebi1.cfg ;
endif
Showing posts with label emmc boot. Show all posts
Showing posts with label emmc boot. Show all posts
3/07/2013
2/26/2013
How to dump PBL with trace32 on QRD8x25 platform
local &filename
local &mmu_cr
local &ttb
local &dacr
;;refer to pbl.scl
d.save.binary c:\temp\pbl.bin 0xFFFF0000--0xFFFFFFFF
d.save.binary c:\temp\pbl_stack.bin 0x80000000--0x8003FFFF
d.save.binary c:\temp\pbl_data.bin 0xFFFEF000--0xFFFEFFFF
;d.load.binary pbl.bin 0xFFFF0000--0xFFFFFFFF
;d.load.binary pbl_stack.bin 0x80000000--0x8003FFFF
;d.load.binary pbl_data.bin 0xFFFEF000--0xFFFEFFFF
&filename="c:\temp\MMU_log.cmm"
open #1 "&filename" /create
&mmu_cr=data.long(c15:0x1)
&ttb=data.long(c15:0x2)
&dacr=data.long(c15:0x3)
write #1 "B::"
write #1 "PER.S C15:0x3 %LONG "+"&dacr"
write #1 "PER.S C15:0x2 %LONG "+"&ttb"
write #1 "PER.S C15:0x1 %LONG "+"&mmu_cr"
write #1 "ENDDO"
close #1
&filename="c:\temp\register_log.cmm"
store &filename hex register
local &mmu_cr
local &ttb
local &dacr
;;refer to pbl.scl
d.save.binary c:\temp\pbl.bin 0xFFFF0000--0xFFFFFFFF
d.save.binary c:\temp\pbl_stack.bin 0x80000000--0x8003FFFF
d.save.binary c:\temp\pbl_data.bin 0xFFFEF000--0xFFFEFFFF
;d.load.binary pbl.bin 0xFFFF0000--0xFFFFFFFF
;d.load.binary pbl_stack.bin 0x80000000--0x8003FFFF
;d.load.binary pbl_data.bin 0xFFFEF000--0xFFFEFFFF
&filename="c:\temp\MMU_log.cmm"
open #1 "&filename" /create
&mmu_cr=data.long(c15:0x1)
&ttb=data.long(c15:0x2)
&dacr=data.long(c15:0x3)
write #1 "B::"
write #1 "PER.S C15:0x3 %LONG "+"&dacr"
write #1 "PER.S C15:0x2 %LONG "+"&ttb"
write #1 "PER.S C15:0x1 %LONG "+"&mmu_cr"
write #1 "ENDDO"
close #1
&filename="c:\temp\register_log.cmm"
store &filename hex register
2/01/2013
How to generate one image for QRD8x25?
produce the dataio, please refer to the step below:
1, Create a directory(ex:factoryimage),and copy all the ap & bp images&backupnv into it.
2. copy emmcswdownload.exe (C:\Program Files\Qualcomm\QPST\bin) into the directory .
3. run "cmd",switch to the dir "C:\Program Files\Qualcomm\QPST\bin", exec "emmcswdownload.exe -f factoryimage.bin"
4. the next action is like normal download (not emergency download) .
5, After downloading, the factoryimage will be produced in the directory.
1, Create a directory(ex:factoryimage),and copy all the ap & bp images&backupnv into it.
2. copy emmcswdownload.exe (C:\Program Files\Qualcomm\QPST\bin) into the directory .
3. run "cmd",switch to the dir "C:\Program Files\Qualcomm\QPST\bin", exec "emmcswdownload.exe -f factoryimage.bin"
4. the next action is like normal download (not emergency download) .
5, After downloading, the factoryimage will be produced in the directory.
12/29/2012
How to remove internal mass storage on QRD Android (ICS)
1. remove the "UDISK" partition from the partition table, and correspondingly enlarge the size of Userdata partition:
modem_proc\core\storage\tools\jsdcc\partition_load_pt\partiton.xml
Then regenerate rawprogram0.xml and patch0.xml
2. set the new size for BOARD_USERDATAIMAGE_PARTITION_SIZE in file /device/qcom/msm7626a/boardconfig.mk
3. change persist.sys.emmcpartition property to 0 in the file /device/qcom/msm7627a/system.prop
persist.sys.emmcpartition=0
and make sure persist.sys.emmcsdcard.enabled is disabled(0)
4. remove the USB lun item in file kernel/drivers/usb/gadget/android.c:
function 'mass_storage_function_init':
<...>
#if 0 // modified this line, remove internal stroage.
config->fsg.luns[0].cdrom = 0; // sdcard
config->fsg.luns[1].cdrom = 0; // internal storage
config->fsg.luns[2].cdrom = 1; // cdrom
#else
config->fsg.luns[0].cdrom = 0; // sdcard
config->fsg.luns[1].cdrom = 1; // cdrom
modem_proc\core\storage\tools\jsdcc\partition_load_pt\partiton.xml
Then regenerate rawprogram0.xml and patch0.xml
2. set the new size for BOARD_USERDATAIMAGE_PARTITION_SIZE in file /device/qcom/msm7626a/boardconfig.mk
3. change persist.sys.emmcpartition property to 0 in the file /device/qcom/msm7627a/system.prop
persist.sys.emmcpartition=0
and make sure persist.sys.emmcsdcard.enabled is disabled(0)
4. remove the USB lun item in file kernel/drivers/usb/gadget/android.c:
function 'mass_storage_function_init':
<...>
#if 0 // modified this line, remove internal stroage.
config->fsg.luns[0].cdrom = 0; // sdcard
config->fsg.luns[1].cdrom = 0; // internal storage
config->fsg.luns[2].cdrom = 1; // cdrom
#else
config->fsg.luns[0].cdrom = 0; // sdcard
config->fsg.luns[1].cdrom = 1; // cdrom
12/20/2012
How to download modem image via fastboot with QRD8x25 platform
Note: it is only for emmc boot.
1.change mbr_fill_name() in the $(AP_CODE)/bootable/bootloader/lk/platform/msm_shared/partition_parser.c
(1).change "memcpy(partition_ent->name, "sbl1", 4);" to "memcpy(partition_ent->name, "qcsblhd_cfgdata", 15);"
(2).change "memcpy(partition_ent->name, "sbl3", 4);" to
"memcpy(partition_ent->name, "qcsbl", 5);"
(3).change "memcpy(partition_ent->name, "rpm", 3);" to
"memcpy(partition_ent->name, "emmc_appsboot", 13);"
(4).change "memcpy(partition_ent->name, "tz", 2);" to "memcpy(partition_ent->name, "oemsbl", 6);"
(5).delete all the functions when the type is "MBR_MODEM_TYPE" or MBR_MODEM_TYPE2, and execute "memcpy(partition_ent->name, "fat", 3);" when the type is "MBR_MODEM_TYPE" or "MBR_MODEM_TYPE" .
2.re-build emmc_appsboot*.mbn and download them into the phone;
3.generate oemsbl.bin and emmc_appsboot.bin
the struct of the oemsbl.bin is
(oemsblhd.mbn + some 0x00) + oemsbl.mbn
|<----------512byte-------->|
the struct of the emmc_appsboot.bin is
(emmc_appsboothd.mbn + some 0x00) + emmc_appsboot.mbn
|<-------------512byte----------->|
you can download the pre-fastboot tool to generate these images.
chick here to download pre-fastboot:
https://docs.google.com/open?id=0B8FEzcDZzbOFZGRtOS1ZMmhPSm8
4.Then you can test to use the following command to download images in the fastboot mode:
fastboot flash qcsblhd_cfgdata qcsblhd_cfgdata.mbn
fastboot flash qcsbl qcsbl.mbn
fastboot flash oemsbl oemsb.bin
fastboot flash fat fat.bin
fastboot flash emmc_appsboot emmc_appsboot.bin
1.change mbr_fill_name() in the $(AP_CODE)/bootable/bootloader/lk/platform/msm_shared/partition_parser.c
(1).change "memcpy(partition_ent->name, "sbl1", 4);" to "memcpy(partition_ent->name, "qcsblhd_cfgdata", 15);"
(2).change "memcpy(partition_ent->name, "sbl3", 4);" to
"memcpy(partition_ent->name, "qcsbl", 5);"
(3).change "memcpy(partition_ent->name, "rpm", 3);" to
"memcpy(partition_ent->name, "emmc_appsboot", 13);"
(4).change "memcpy(partition_ent->name, "tz", 2);" to "memcpy(partition_ent->name, "oemsbl", 6);"
(5).delete all the functions when the type is "MBR_MODEM_TYPE" or MBR_MODEM_TYPE2, and execute "memcpy(partition_ent->name, "fat", 3);" when the type is "MBR_MODEM_TYPE" or "MBR_MODEM_TYPE" .
2.re-build emmc_appsboot*.mbn and download them into the phone;
3.generate oemsbl.bin and emmc_appsboot.bin
the struct of the oemsbl.bin is
(oemsblhd.mbn + some 0x00) + oemsbl.mbn
|<----------512byte-------->|
the struct of the emmc_appsboot.bin is
(emmc_appsboothd.mbn + some 0x00) + emmc_appsboot.mbn
|<-------------512byte----------->|
you can download the pre-fastboot tool to generate these images.
chick here to download pre-fastboot:
https://docs.google.com/open?id=0B8FEzcDZzbOFZGRtOS1ZMmhPSm8
4.Then you can test to use the following command to download images in the fastboot mode:
fastboot flash qcsblhd_cfgdata qcsblhd_cfgdata.mbn
fastboot flash qcsbl qcsbl.mbn
fastboot flash oemsbl oemsb.bin
fastboot flash fat fat.bin
fastboot flash emmc_appsboot emmc_appsboot.bin
6/22/2012
How to mount the FAT partition as a Mass Storage device in 7x30 Android build?
For 7x30 eMMC builds, the partition.xml defines the partition layout. And some partition can be formatted as FAT partition.
In some use cases, it is needed for some FAT partition to be mounted as Mass Storage device, some users can drag-and-drop files to and from PC the eMMC 's FAT partition.
The following steps are guidelines for how to do it:
1. In Android UI, go to "Qualcomm Setting --> USB Mass Storage" and click for yes.
2. In Android UI, go to "Qualcomm Setting --> USB Composition " and click on "DIAG+MODEM+NMA+MSC"
3. Adb Shell in to Android, and go to "/dev/block/" and do a list to show all partitions on eMMC. You should see "mmcblk0pN", where N is the order of partitions on eMMC. Then identify the designated partition which is FAT format, as an example we assume partition 0 is the FAT partition we need to mount as Mass Storage device.
4. # mkdir /data/fat
5. # mount -t vfat -r -w /dev/block/mmcblk0p1 /data/fat
6. # echo "/dev/block/mmcblk0p1" > /sys/devices/platform/msm_hsusb/gadget/lun0/file
7. Then unplug and re-plug the device to PC, and you should see eMMC FAT partition from PC
In some use cases, it is needed for some FAT partition to be mounted as Mass Storage device, some users can drag-and-drop files to and from PC the eMMC 's FAT partition.
The following steps are guidelines for how to do it:
1. In Android UI, go to "Qualcomm Setting --> USB Mass Storage" and click for yes.
2. In Android UI, go to "Qualcomm Setting --> USB Composition " and click on "DIAG+MODEM+NMA+MSC"
3. Adb Shell in to Android, and go to "/dev/block/" and do a list to show all partitions on eMMC. You should see "mmcblk0pN", where N is the order of partitions on eMMC. Then identify the designated partition which is FAT format, as an example we assume partition 0 is the FAT partition we need to mount as Mass Storage device.
4. # mkdir /data/fat
5. # mount -t vfat -r -w /dev/block/mmcblk0p1 /data/fat
6. # echo "/dev/block/mmcblk0p1" > /sys/devices/platform/msm_hsusb/gadget/lun0/file
7. Then unplug and re-plug the device to PC, and you should see eMMC FAT partition from PC
6/01/2012
How PBL works with partition.bin in eMMC boot solution in the MSM7x30 / MSM8255
1.Partition.xml
<physical_partition number="0">
<primary order="1" type="c" bootable="false" label="FAT" size="819200"
readonly="false">
</primary>
<primary order="2" type="4d" bootable="true" label="CFG_DATA" size="1000"
readonly="true">
<file name="dbl.mbn" offset="0"/>
</primary>
<primary order="3" type="46" bootable="false" label="OEMSBL" size="3000"
readonly="false">
<file name="osbl.mbn" offset="0"/>
</primary>
2. MBR in Partition.bin(example)
MBR is programmed in the first block of physical user partition and it has
four entries including one link to EBR.
Here, 0x1BE(446 + code size(440) + 4 bytes disk sig + 2 bytes null bytes) is
the start of first entry
of partition_entry in structure listed in section 5. The contents will be
flashed to The first sector
of eMMC card user physical partition when use mjsdload.cmm or msp to program
the partition.bin to the
eMMC card. More detail can be found in ms_program_card.c.
such as the following partition.bin matched the partition.xml listed above
000001b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000001c0h: 00 00 0C 00 00 00 01 00 00 00 00 80 0C 00 80 00 ; ...........�.�
000001d0h: 00 00 4D 00 00 00 01 80 0C 00 E8 03 00 00 00 00 ; ..M....�.?....
000001e0h: 00 00 46 00 00 00 E9 83 0C 00 B8 0B 00 00 00 00 ; ..F...�..?....
000001f0h: 00 00 05 00 00 00 A1 8F 0C 00 40 42 0F 00 55 AA ; ......�..@B..U
0x1BE is FAT (MBR_ENTRY_0)
0x1BE = boot able = 0 FALSE
0x1BE+4 = type = 0xC = FAT
0x1BE+8= start sector = 0x1
0x1BE+0xC = Size = 0xC0800 = 8192000 (if it is not the last entry of partition
, the size is matched to partition.xml)
0x1BE+0x10 =0x1CE is the format of MBR_entry_1
0x1CE is DBL (MBR_ENTRY_1) DBL is taken as boot able partition.
0x1CE = Boot able = 0x80 = TRUE.
0x1CE+4 = 0x1D2 = type = 0x4D
0x1D2+4 = 0x1D6 = start sector = 0xC08001 = 819201
0x1D6+4 = size = 0x300
0x1DE is the osbl(MBR_ENTRY_2)
0x1EE is the EBR entry
0x1EE+4 = type = 0x5(EBR type)
The size of last entry in MBR is automatically align to WP_GROUP_SIZE(64MB),
that means it will fill the 64MB space.
3. EBR in partition bin(example)
Each EBR has 512 bytes , it has one partition entry and one link to next EBR.
example for the FOTA partition in EBR.
in XML it is
<extended order="2" type="4c" label="FOTA" size="64000" readonly="false">
</extended>>
in partiton.bin, it is
000005b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000005c0h: 00 00 4C 00 00 00 5E 70 03 00 00 FA 00 00 00 00 ; ..L...^p...?...
000005d0h: 00 00 05 00 00 00 02 00 00 00 01 18 00 00 00 00 ; ................
000005e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000005f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ; ..............U
the EBR will be programmed to type is
0x5C2 = 0xC = FOTA
0x5C6 = start sector = 0030705E (start location of EBR, the content will
write to next adjacent sector)
0x5EA = size = 0x0000FA00 = 64000 (bytes)
If the entry is the last entry partition in EBR, then the size of the last
entry will automatically fill up to the size of the
card(physical user partition)
4. How PBL read the MBR.
In PBL, we will read the first sector (512 bytes) and map to following structure.
flash_status = pbl_sdc_read_sector_bytes( sdc_dev, 0, 0, (uint32)sizeof(
mbr_sector_t), (uint8*) &mbr);
So we can see
Last 16bytes is 0x55AA for the MBR magic number
The start sector and length in partition_entry will match to the start sector
and length in MBR_ENTRY_x(X=0…3)
status is map to the boot able field in the MBR_ENTRY_X(X=0…3)
/* MBR structure definition */
typedef __packed struct
{
/* Code region. Unused but leave it here to compliance with MBR standard */
uint8 code_section[CODE_AREA_SIZE];
CODE_AREA_SIZE = 440bytes.
/* Disk Signature */
uint32 disk_sig;
/* NULL */
uint16 null_bytes;
/* 4 partition table entry */
partition_entry_t partition_entry[4];
/* 0x55AA */
uint16 mbr_signature;
}mbr_sector_t;
typedef __packed struct partition_entry
{
/* current status unused */
uint8 status;
/* CHS address of the first sector, unused */
CHS_type CHS_start;
/* unused */
uint8 partition_type;
/* CHS address of the last sector, unused */
CHS_type CHS_end;
/* logical address of first sector, in sectors */
uint32 start_sector;
/* length of partion, in sectors*/
uint32 lenght;
}partition_entry_t ;
<physical_partition number="0">
<primary order="1" type="c" bootable="false" label="FAT" size="819200"
readonly="false">
</primary>
<primary order="2" type="4d" bootable="true" label="CFG_DATA" size="1000"
readonly="true">
<file name="dbl.mbn" offset="0"/>
</primary>
<primary order="3" type="46" bootable="false" label="OEMSBL" size="3000"
readonly="false">
<file name="osbl.mbn" offset="0"/>
</primary>
2. MBR in Partition.bin(example)
MBR is programmed in the first block of physical user partition and it has
four entries including one link to EBR.
Here, 0x1BE(446 + code size(440) + 4 bytes disk sig + 2 bytes null bytes) is
the start of first entry
of partition_entry in structure listed in section 5. The contents will be
flashed to The first sector
of eMMC card user physical partition when use mjsdload.cmm or msp to program
the partition.bin to the
eMMC card. More detail can be found in ms_program_card.c.
such as the following partition.bin matched the partition.xml listed above
000001b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000001c0h: 00 00 0C 00 00 00 01 00 00 00 00 80 0C 00 80 00 ; ...........�.�
000001d0h: 00 00 4D 00 00 00 01 80 0C 00 E8 03 00 00 00 00 ; ..M....�.?....
000001e0h: 00 00 46 00 00 00 E9 83 0C 00 B8 0B 00 00 00 00 ; ..F...�..?....
000001f0h: 00 00 05 00 00 00 A1 8F 0C 00 40 42 0F 00 55 AA ; ......�..@B..U
0x1BE is FAT (MBR_ENTRY_0)
0x1BE = boot able = 0 FALSE
0x1BE+4 = type = 0xC = FAT
0x1BE+8= start sector = 0x1
0x1BE+0xC = Size = 0xC0800 = 8192000 (if it is not the last entry of partition
, the size is matched to partition.xml)
0x1BE+0x10 =0x1CE is the format of MBR_entry_1
0x1CE is DBL (MBR_ENTRY_1) DBL is taken as boot able partition.
0x1CE = Boot able = 0x80 = TRUE.
0x1CE+4 = 0x1D2 = type = 0x4D
0x1D2+4 = 0x1D6 = start sector = 0xC08001 = 819201
0x1D6+4 = size = 0x300
0x1DE is the osbl(MBR_ENTRY_2)
0x1EE is the EBR entry
0x1EE+4 = type = 0x5(EBR type)
The size of last entry in MBR is automatically align to WP_GROUP_SIZE(64MB),
that means it will fill the 64MB space.
3. EBR in partition bin(example)
Each EBR has 512 bytes , it has one partition entry and one link to next EBR.
example for the FOTA partition in EBR.
in XML it is
<extended order="2" type="4c" label="FOTA" size="64000" readonly="false">
</extended>>
in partiton.bin, it is
000005b0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000005c0h: 00 00 4C 00 00 00 5E 70 03 00 00 FA 00 00 00 00 ; ..L...^p...?...
000005d0h: 00 00 05 00 00 00 02 00 00 00 01 18 00 00 00 00 ; ................
000005e0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ; ................
000005f0h: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA ; ..............U
the EBR will be programmed to type is
0x5C2 = 0xC = FOTA
0x5C6 = start sector = 0030705E (start location of EBR, the content will
write to next adjacent sector)
0x5EA = size = 0x0000FA00 = 64000 (bytes)
If the entry is the last entry partition in EBR, then the size of the last
entry will automatically fill up to the size of the
card(physical user partition)
4. How PBL read the MBR.
In PBL, we will read the first sector (512 bytes) and map to following structure.
flash_status = pbl_sdc_read_sector_bytes( sdc_dev, 0, 0, (uint32)sizeof(
mbr_sector_t), (uint8*) &mbr);
So we can see
Last 16bytes is 0x55AA for the MBR magic number
The start sector and length in partition_entry will match to the start sector
and length in MBR_ENTRY_x(X=0…3)
status is map to the boot able field in the MBR_ENTRY_X(X=0…3)
/* MBR structure definition */
typedef __packed struct
{
/* Code region. Unused but leave it here to compliance with MBR standard */
uint8 code_section[CODE_AREA_SIZE];
CODE_AREA_SIZE = 440bytes.
/* Disk Signature */
uint32 disk_sig;
/* NULL */
uint16 null_bytes;
/* 4 partition table entry */
partition_entry_t partition_entry[4];
/* 0x55AA */
uint16 mbr_signature;
}mbr_sector_t;
typedef __packed struct partition_entry
{
/* current status unused */
uint8 status;
/* CHS address of the first sector, unused */
CHS_type CHS_start;
/* unused */
uint8 partition_type;
/* CHS address of the last sector, unused */
CHS_type CHS_end;
/* logical address of first sector, in sectors */
uint32 start_sector;
/* length of partion, in sectors*/
uint32 lenght;
}partition_entry_t ;
5/10/2012
EMMC Factory image generation
QPST 2.7.366 is required for the operation.
Factory image generation:
emmcswdownload.exe -f factory.bin -x AMSS\products\7x30\core\storage\tools\jsdcc\partition_load_pt\partition.xml -s 4G -g 8M -p E:\build\emmc\;
Download factory image:
emmcswdownload.exe -i factory.bin -w G:\
emmcswdownload.exe -i factory.bin -w G:\
factory image you can not use ext4 sparse image. and sparse image can only be download by fastboot. If you develop you own tools, you can support sparse image and don't need factory image for DataIO.
How to generate the 7x30_msimage.mbn
Background
In all 7x30/8660, the default 7x30[8660]_msiamge.mbn is generated by Qualcomm, but customers want to have their own msimge.mbn to flash with emmc software download tools supported from QPST 2.7.366
Steps to generate the 7x30_msimage.mbn
1.Change the partition.xml to partition_customer.xml and prepare the dbl.mbn/osbl.mbn in the same folder.
Here, the 7x30_msimage.mbn is a small image has the partition/dbl/osbl . It will be downloaded in emergency download mode with eMMC software download tools.
<?xml version="1.0"?>
<!DOCTYPE image SYSTEM "weaver-1.0.dtd">
<image>
<physical_partition number="0">
<primary order="1" type="4d" bootable="true" label="CFG_DATA" size="1000" readonly="true">
<file name="dbl.mbn" offset="0"/>
</primary>
<primary order="2" type="46" bootable="false" label="OEMSBL" size="3000" readonly="false">
<file name="osbl.mbn" offset="0"/>
</primary>
</physical_partition>
</image>
2.python PartitioningTool.py partition_customer.xml
3. python msp.py rawprogram0.xml size
Size is in KB,such as 2MB is enough for simple imge
python msp.py rawprogram0.xml 2048
the singleimg.bin will be generated
4.Change the singleimage.bin to 7x30_msimage.mbn
<?xml version="1.0"?>
<!DOCTYPE image SYSTEM "weaver-1.0.dtd">
<image>
<physical_partition number="0">
<primary order="1" type="4d" bootable="true" label="CFG_DATA" size="1000" readonly="true">
<file name="dbl.mbn" offset="0"/>
</primary>
<primary order="2" type="46" bootable="false" label="OEMSBL" size="3000" readonly="false">
<file name="osbl.mbn" offset="0"/>
</primary>
</physical_partition>
</image>
2.python PartitioningTool.py partition_customer.xml
3. python msp.py rawprogram0.xml size
Size is in KB,such as 2MB is enough for simple imge
python msp.py rawprogram0.xml 2048
the singleimg.bin will be generated
4.Change the singleimage.bin to 7x30_msimage.mbn
QPST-Software Download to the SD card
Loading the hex image to an SD card
Loading the hex image to an SD card can be done with newer devices that use a mass storage chip like eMMC or SD card in place of NOR or NAND flash. If you use QPST 2.7.368 and newer we released new MPRG7x30.hex files. However, these files have not been picked up in a lot of the builds yet.
Getting error 852 while trying to load the image to the card
Error 852 means: "Could not open downloader in eMMC USER mode". Basically this means your flash programmer (PRG7x30_SDC4.hex) doesn't support the new way (USER mode) of writing the boot loader (7x30_msimage.mbn) to the SD device.
If you are getting this error instead of the string it means you are still using a version of QPST prior to 2.7.368 so you should be okay using MPRG7x30.hex from your build.
Loading the image on the SD card on a SURF
From what we know, the SD slot on SURFs is not properly wired to power up on reset so you cannot use SDC4 on SURF. If you have a blue wired FFA or Fluid then you can use uSD (micro SD) card and use MPRG7x30_SDC4.hex. For SURF you should always use eMMC plugged in SDC2 or wee card plugged in just above SDC2 slot. For that you need to use MPRG7x30.hex instead of MPRG7x30_SDC4.hex.
Including the QCN with the binary image created by the eMMC Software Download agent
The QCN file is never copied to a phone. The file is just a container for NV items for Qualcomm PC-based applications. The QCN file contains NV items (which become item files on the target device) and item files.
We have no tools to alter a eMMC factory image. When creating an eMMC factory image you would have to create file system partitions (FAT, ext3, or any other format) and find a way to populate these partitions with files that have the values and names of the NV items.
Loading the hex image to an SD card can be done with newer devices that use a mass storage chip like eMMC or SD card in place of NOR or NAND flash. If you use QPST 2.7.368 and newer we released new MPRG7x30.hex files. However, these files have not been picked up in a lot of the builds yet.
Getting error 852 while trying to load the image to the card
Error 852 means: "Could not open downloader in eMMC USER mode". Basically this means your flash programmer (PRG7x30_SDC4.hex) doesn't support the new way (USER mode) of writing the boot loader (7x30_msimage.mbn) to the SD device.
If you are getting this error instead of the string it means you are still using a version of QPST prior to 2.7.368 so you should be okay using MPRG7x30.hex from your build.
Loading the image on the SD card on a SURF
From what we know, the SD slot on SURFs is not properly wired to power up on reset so you cannot use SDC4 on SURF. If you have a blue wired FFA or Fluid then you can use uSD (micro SD) card and use MPRG7x30_SDC4.hex. For SURF you should always use eMMC plugged in SDC2 or wee card plugged in just above SDC2 slot. For that you need to use MPRG7x30.hex instead of MPRG7x30_SDC4.hex.
Including the QCN with the binary image created by the eMMC Software Download agent
The QCN file is never copied to a phone. The file is just a container for NV items for Qualcomm PC-based applications. The QCN file contains NV items (which become item files on the target device) and item files.
We have no tools to alter a eMMC factory image. When creating an eMMC factory image you would have to create file system partitions (FAT, ext3, or any other format) and find a way to populate these partitions with files that have the values and names of the NV items.
QPST-Emergency Download Support
What is this feature?
The QPST Software Download app shows an option called "Use Emerg. Host D/L". This option was introduced in QPST 2.7.335 and higher. When enabled, it makes QPST look for a flash programmer named eNPRGxxxx.hex. If that file isn't present in the AMSS build then the download will fail. The only implementation in QPST for the Emergency Boot Loader is to prefix an "e" to the flash programmer name if the user selects "Use Emerg. Host D/L". See document 80-VP758-1 (Emergency Download Feature).
Once the flash has been altered, you may have damaged any recovery code that is part of the AMSS image. To get around this, the emergency downloader is actually part of the MSM itself, resident in a ROM along with the primary boot loader (PBL). It can't be overwritten. This should even allow you to enter download mode if you have a blank flash. The secure boot architecture has validation code that checks the digital signature of the next block of code. If it doesn't match (either because of a corrupted, hacked, or blank image) it would activate the emergency downloader.At this stage, using QPST's Emergency Download option couldbe selected and the ehostdl binary could be downloaded to the IMEM. This wouldfacilitate the download of entire AMSS image through the ehostdl downloadmechanism. Ifthere is any error seen in accessing flash or any error seen in PBL, then thephone would go to download mode in PBL. Hence the entire boot, AMSS images canbe re-flashed or downloaded using this emergency download feature.
Some targets, such as the 8650 or M9k based ones, do not support the "Emergency Download" through USB, even though the USB function is supported. The selection of USB or UART for Emergency Download has already been made in the Boot ROM of the chip, and cannot be changed without a new chip revision. All chips released in 2009 and beyond will support USB.
Which targets support this feature?
Please refer to 80-VJ116-1 (Secure Boot 2.0 Architecture) to see which targets support emergency download ePRGxxx.hex using which serial interface (UART2, UART1, HS-USB) for those targets which uses Secure Boot 2.0.
What about targets that support Secure Boot 1.0?
MSM6290 uses Secure boot 1.0 and is not covered by 80-VJ116-1 (Secure Boot 2.0 Architecture). We do not have any other document listing all the targets supporting emergency download. However, the MSM6290 also supports ePRGxxx.hex.
How does a customer implement this feature in their PST like tool?
The only implementation in QPST for the Emergency Boot Loader is to prefix an "e" to the flash programmer name if the user selects "Use Emerg. Host D/L".
The emergency downloader has to be created by the AMSS build.
Automating the emergency download feature
Starting with QPST version 2.7.362 there will be an example of how to automate this feature. The example Perl script is "swdl_DownloadBySettings.pl".
We have support for blank flash programming of partition 0 using rawprogram0.xml and patch0.xml. We don't have support for meta builds or other partitions at this time. The download support is independent of the device (MSM8960), but is dependent on the flash programmer that is built during the AMSS build process for a device.
The emergency download a second time on the same device.
You cannot use this feature twice consecutevly on one device. This feature is for use with blank flash when the device is running in the PBL. Once the eNPRGxxx.hex file was loaded once, you need to use the normal download mode (uncheck 'use emerg...' box).
Secure Boot 3.0 support
Secure Boot 3.0 is only supported by eMMC flash devices and not used on NAND flash. For eMMC the download is controlled by the XML document produced by the AMSS build. In this case the images used by SB 3.0 are just loaded into partitions on the eMMC device like other AMSS images.
You need to use emmcswdownload.exe to download to devices that use eMMC flash devices. However the current version of QPST does not completely support the 8660 eMMC device.
There is no automation support for Secure Boot 3.0 via the QPST automation interface. The "swdl_DownloadBySettings.pl" script does not support Secure Boot 3.0 therefore it will not work with devices that have this type of boot.
Document error on element type "root" and name/value"<image> tag no longer supported" error
This type of programming, using partition.xml, is no longer supported. Start with version 2.7.370 and going forward, QPST only supports rawprogram0.xml format. You will have to modify your build process to create the new XML file.
If you still cannot load the rawprogram0.xml file, verify there are no lines that have sparse="true" value. Sparse file format is not supported by QPST. You either have to convert the file to a non-sparse format or skip these items entirely.
Please note that in our builds we do not arbitrarily create this sparse tag. The sparse tag is needed because Android targets use "sparse" files that are meant to be loaded via fastboot. In a nutshell the sparse tag saves you from accidentally loading a "sparse" file that fastboot needs to uncompress first.
The QPST Software Download app shows an option called "Use Emerg. Host D/L". This option was introduced in QPST 2.7.335 and higher. When enabled, it makes QPST look for a flash programmer named eNPRGxxxx.hex. If that file isn't present in the AMSS build then the download will fail. The only implementation in QPST for the Emergency Boot Loader is to prefix an "e" to the flash programmer name if the user selects "Use Emerg. Host D/L". See document 80-VP758-1 (Emergency Download Feature).
Once the flash has been altered, you may have damaged any recovery code that is part of the AMSS image. To get around this, the emergency downloader is actually part of the MSM itself, resident in a ROM along with the primary boot loader (PBL). It can't be overwritten. This should even allow you to enter download mode if you have a blank flash. The secure boot architecture has validation code that checks the digital signature of the next block of code. If it doesn't match (either because of a corrupted, hacked, or blank image) it would activate the emergency downloader.At this stage, using QPST's Emergency Download option couldbe selected and the ehostdl binary could be downloaded to the IMEM. This wouldfacilitate the download of entire AMSS image through the ehostdl downloadmechanism. Ifthere is any error seen in accessing flash or any error seen in PBL, then thephone would go to download mode in PBL. Hence the entire boot, AMSS images canbe re-flashed or downloaded using this emergency download feature.
Some targets, such as the 8650 or M9k based ones, do not support the "Emergency Download" through USB, even though the USB function is supported. The selection of USB or UART for Emergency Download has already been made in the Boot ROM of the chip, and cannot be changed without a new chip revision. All chips released in 2009 and beyond will support USB.
Which targets support this feature?
Please refer to 80-VJ116-1 (Secure Boot 2.0 Architecture) to see which targets support emergency download ePRGxxx.hex using which serial interface (UART2, UART1, HS-USB) for those targets which uses Secure Boot 2.0.
- QSC6195 using HS-USB
- QSC6295 using HS-USB
- QSC6240 using UART2 at 115 kbps.
- QSC6270 using UART2 at 115 kbps.
- MSM6246 using UART2. (Tested on SURF only)
- MSM6290 using UART2. (Tested on SURF only)
- MSM7x30 using HS-USB.
- MDM8200 (No eNPRFxxx.hex as of 1/16/2009)
- MDM8900 (No eNPRFxxx.hex as of 1/16/2009)
- FRB has recently (1/2009) approved supporting it on QSD8650 using UART1.
- FRB has recently (1/2009) approved supporting it on QSD8250 using UART1.
- All others need JTAG recovery.
Secure Boot 2.0 Architecture is supported on the following targets:
- QSC6195™
- QSC6240™
- QSC6246™
- QSC6270™
- QSC6295™
- QSC1100™
- MSM7x30
- MDM8200™/MDM8900™
- QSD8250™/QSD8650™
- All future chipsets will have it as default boot mechanism
Emergency download mode in PBL is supported on the following targets:
- MSM6246™ (UART2)
- MSM6290™ (UART2)
- QSC6195™ (HS-USB)
- QSC6295™ (HS-USB)
- QSC6240™ (UART2)
- QSC6270™ (UART2)
- QSC7x30 (HS-USB)
- MDM8200™/MDM8900™ (No eNPRGxxx.hex at this point 01/16/09)
- QSD8650™ (UART1)
What about targets that support Secure Boot 1.0?
MSM6290 uses Secure boot 1.0 and is not covered by 80-VJ116-1 (Secure Boot 2.0 Architecture). We do not have any other document listing all the targets supporting emergency download. However, the MSM6290 also supports ePRGxxx.hex.
How does a customer implement this feature in their PST like tool?
The only implementation in QPST for the Emergency Boot Loader is to prefix an "e" to the flash programmer name if the user selects "Use Emerg. Host D/L".
The emergency downloader has to be created by the AMSS build.
Automating the emergency download feature
Starting with QPST version 2.7.362 there will be an example of how to automate this feature. The example Perl script is "swdl_DownloadBySettings.pl".
We have support for blank flash programming of partition 0 using rawprogram0.xml and patch0.xml. We don't have support for meta builds or other partitions at this time. The download support is independent of the device (MSM8960), but is dependent on the flash programmer that is built during the AMSS build process for a device.
The emergency download a second time on the same device.
You cannot use this feature twice consecutevly on one device. This feature is for use with blank flash when the device is running in the PBL. Once the eNPRGxxx.hex file was loaded once, you need to use the normal download mode (uncheck 'use emerg...' box).
Secure Boot 3.0 support
Secure Boot 3.0 is only supported by eMMC flash devices and not used on NAND flash. For eMMC the download is controlled by the XML document produced by the AMSS build. In this case the images used by SB 3.0 are just loaded into partitions on the eMMC device like other AMSS images.
You need to use emmcswdownload.exe to download to devices that use eMMC flash devices. However the current version of QPST does not completely support the 8660 eMMC device.
There is no automation support for Secure Boot 3.0 via the QPST automation interface. The "swdl_DownloadBySettings.pl" script does not support Secure Boot 3.0 therefore it will not work with devices that have this type of boot.
Document error on element type "root" and name/value"<image> tag no longer supported" error
This type of programming, using partition.xml, is no longer supported. Start with version 2.7.370 and going forward, QPST only supports rawprogram0.xml format. You will have to modify your build process to create the new XML file.
If you still cannot load the rawprogram0.xml file, verify there are no lines that have sparse="true" value. Sparse file format is not supported by QPST. You either have to convert the file to a non-sparse format or skip these items entirely.
Please note that in our builds we do not arbitrarily create this sparse tag. The sparse tag is needed because Android targets use "sparse" files that are meant to be loaded via fastboot. In a nutshell the sparse tag saves you from accidentally loading a "sparse" file that fastboot needs to uncompress first.
4/23/2012
How to build eMMC flash programmer MPRG7x30.hex and 7x30_msimage.mbn?
How to build eMMC flash programmer MPRGXXXX.hex and msimage.mbn?
1. Please check if the SConscript is provided in "modem_proc/core p/tools/emmcbld/bulid". If not, you cannot build it with this release.
2. set build environment by executing RVCTXX.bat in build/ms folder
3. go to "modem_proc/core/bsp/build"
4. execute "build emmcbld BUILD_ID=xxxxxxxx"
5. The generated image is located in modem_proc/build/ms/bin/EMMCBLD/
6. MPRGXXXX.hex is eMMC programmer used to communicate with QPST to download msimage.mbn into eMMC.
7. msimage.mbn is used to enumerate the device as a USB mass storage device for all the image updates.
Using command line to creat 7x30_msimage.mbn
The eMMC Software Download Tool can also be used in Command Line mode for factory automation and creating boot images.
First find the location of your QPST install, normally under C:\Program Files(x86)\Qualcomm\ 5 QPST\bin, that contains your emmcswdownload.exe file. You can either map this location to your 6 path or refer to it directly from the cmd window.
The following command line options are supported for emmcswdownload.exe:
-f <filename> : direct output to <filename> instead of selected device
-s <size enum> : mass storage device size = { “1G”, “2G”, “4G”, etc }
-g <size enum> : write protect group size = { “4M”, “8M”, “16M”, etc }
-x <filename> : partition description file
-p <directory> : search path = path1;path2;…. Etc
-L <filename> : list all connected mass storage drives to <filename>
-i <filename> : image file to write to mass storage device
-w <drive> : mass storage drive to write image file to
In this command line:
–s and –g options are required, even if no sections are marked as read only
–s size is only used to set the size of the last partition; it does not affect the size of the output image
–g is the write-protect size for partitions marked as read only; if there are multiple read-only partitions, only the first and last partitions will be aligned on a protect size boundary
–L only dumps to the output file, not to stdout
emmcswdownload -f \tmp\7x30_msimage.mbn -x E:\emmc\partition_boot.xml -s 1G -g 64M -p E:\emmc\;
Subscribe to:
Posts (Atom)