How to configure the uart2dm to pin EBI2_A_D_7, EBI2_A_D_6 pin.
Gpios 19,20,21 and 108 configured for SDC controller.
So we can't use the same gpios for UART2DM.
Instead,we can configure UART2DM on EBI2 [9:6] data lines by setting the "emmc_boot" bit of TMUX_EBI2 to 1.
When you write the "emmc_boot" to 1, EBI2 functionality will be lost and EBI2 data lines will be used only for UART2DM functionality.
If you are using NAND boot EBI2 lines are used for NAND support, so you can not configure for UART2 DM on EBI2 port.
If your are using EMMC boot, than you can configure for UART2 DM on EBI2 port.
Register Description :- TMUX_EBI2
The EBI-2 pads can be used for a variety of test and debug modes.
The TMUX_EBI2 register, in conjunction with the TMUX_JTAG register and the MODE pins, control the EBI-2 multiplexing.
Type: Write/Read
Clock: CC_TLMM_CLK
Reset State: 0x00
Bits
4 emmc_boot Set this bit to have concurrent usage of
eMMC boot,uart2dm,ETM,aux jtag.
Note that you will also have to set the
corresponding bits for ETM and Aux jtag
like in normal usage apart from setting this
bit.
3 gp_pdm_sel selects
gp_pdm0 on GPIO[96] and
gp_pdm1 on EBI2_CS2.
2:0 RESERVED Reserved
Sample code changes required from modem side to configure TMUX_EBI2 register to set emmc_boot.
File path :- modem_proc\dal\drivers\tlmm_src\DALTLMMBoot.c
Funtion name :- TLMM_INIT() end of the funtion add the one line code to set emmc_boot bit.
HAL_tlmm_SetPort(HAL_TLMM_EMMC_BOOT_EN,0x01,0x01);
File path :- modem_proc\dal\drivers\tlmm_src\ DALTLMM.c
Funtion name :- TLMM_INIT() end of the funtion add the one line code to set emmc_boot bit.
HAL_tlmm_SetPort(HAL_TLMM_EMMC_BOOT_EN,0x01,0x01);
APPS Side UART Kernel flags modified as follows:
This CONFIG is not set
CONFIG_SERIAL_MSM_CLOCK_CONTROL
Remove the following CONFIGs
-CONFIG_SERIAL_MSM=y
-CONFIG_SERIAL_MSM_CONSOLE=y
-CONFIG_MMC_MSM_SDC3_SUPPORT=y
-CONFIG_MMC_MSM_SDC3_8_BIT_SUPPORT=y
The above mentioned CONFIG need to be added for specific product config file for example :- msm7627a-perf_defconfig.
+CONFIG_SERIAL_HSL=Y
+CONFIG_SERIAL_MSM_HSL_CONSOLE=Y
Add the below line to device\qcom\msm7627a\boardconfig.Mk
BOARD_KERNEL_CMDLINE := console = ttyHSL0, 115200,n8 andriodboot.hardware=qcom
5/28/2012
Which eMMC standard is supported on 7x30 and 8x60
QC supports eMMC 4.4
the features supported include:
- Boot
- Reliable write
- Sleep Mode
- Secure Write Protection
- Secure Memory Block
- HW Reset (Optionally provided)
- Partition feature
- Secure Erase
QC don't support:
- DDR:Our controller doesn't support this. This is an optional feature of e.MMC 4.4 which will be supported from next �gen products
- Low Voltage 1.2v: Optional e.MMC 4.4 feature - Our controller doesn't support this and will not for some time � preference is to stay with the 3/1.8V dual voltage pads and rail support will depend on the commodity. We will migrate to a dual 1.2/1.8V support when 3V becomes obsolete
the features supported include:
- Boot
- Reliable write
- Sleep Mode
- Secure Write Protection
- Secure Memory Block
- HW Reset (Optionally provided)
- Partition feature
- Secure Erase
QC don't support:
- DDR:Our controller doesn't support this. This is an optional feature of e.MMC 4.4 which will be supported from next �gen products
- Low Voltage 1.2v: Optional e.MMC 4.4 feature - Our controller doesn't support this and will not for some time � preference is to stay with the 3/1.8V dual voltage pads and rail support will depend on the commodity. We will migrate to a dual 1.2/1.8V support when 3V becomes obsolete
5/25/2012
How to enable/disable the secure boot authentication feature on MSM8660 by using the JTAG
Notes: This solution does not apply all version MSM8660
This solution does not apply to the RPM JTAG disable cases
This solution only uses for debug purpose.
For some reasons, if you need to to run unsigned software on a secure boot enabled (the AUTH_EN bit in SECURE_BOOT1 register is blown) MSM8660 chip, the following instruction is able to disable the secure boot authentication by using RPM-JTAG.
1. Launch the Daisy Chain RPM-JTAG shortcut (i.e modem_proc\tools\t32\DC7_ARM7_RPM).
2. Execute the cmm script which contain the following command:
system.option resbreak on
system.up
g 0x7ce8 /o /cmd "r.s r0 0x0" ;0x0 for disabling the secure boot authentication
wait 1ms
g
Of course, you can simply modify the cmm script (listed below) to enable the secure boot authentication without blowing SECURE_BOOT1 register on MSM8660 chip by using RPM-JTAG or short the GPIO_76 pin.
system.option resbreak on
system.up
g 0x7ce8 /o /cmd "r.s r0 0x1" ;0x1 for enabling the secure boot authentication
wait 1ms
g
This solution does not apply to the RPM JTAG disable cases
This solution only uses for debug purpose.
For some reasons, if you need to to run unsigned software on a secure boot enabled (the AUTH_EN bit in SECURE_BOOT1 register is blown) MSM8660 chip, the following instruction is able to disable the secure boot authentication by using RPM-JTAG.
1. Launch the Daisy Chain RPM-JTAG shortcut (i.e modem_proc\tools\t32\DC7_ARM7_RPM).
2. Execute the cmm script which contain the following command:
system.option resbreak on
system.up
g 0x7ce8 /o /cmd "r.s r0 0x0" ;0x0 for disabling the secure boot authentication
wait 1ms
g
Of course, you can simply modify the cmm script (listed below) to enable the secure boot authentication without blowing SECURE_BOOT1 register on MSM8660 chip by using RPM-JTAG or short the GPIO_76 pin.
system.option resbreak on
system.up
g 0x7ce8 /o /cmd "r.s r0 0x1" ;0x1 for enabling the secure boot authentication
wait 1ms
g
How to collect JTAG dumps for stability issues on MDM9200/9600?
Following is the procedure which can be used to collect JTAG dumps on MDM9K. All the scripts can be found under build\ms folder
Starting a JTAG session:
1. Start up the Trace32 sessions for ARM9 and QDSP62SW
2. Load the build and symbols (either 'do mjnload' or 'do jload')
3. Run the build ('do std_go' in the ARM9 Trace32)
After crash is seen:
4. Stop the ARM9 side in Trace32 (if not already stopped)
5. Execute 'do std_savelogs' from the ARM9 Trace32 window.
Starting a JTAG session:
1. Start up the Trace32 sessions for ARM9 and QDSP62SW
2. Load the build and symbols (either 'do mjnload' or 'do jload')
3. Run the build ('do std_go' in the ARM9 Trace32)
After crash is seen:
4. Stop the ARM9 side in Trace32 (if not already stopped)
5. Execute 'do std_savelogs' from the ARM9 Trace32 window.
What are the requirement for 8960 Modem JTAG debugging?
You should meet below requirements to use JTAG for 8960 Modem debugging.
Detail:
1) Specific T32 Software (Sep/2011) is needed. should have Proper licenses (Q6, ARM7) installed
2) You should set ISDB flag (refer to KB#00021765 for further detail). Otherwise T32 would refuse JTAG connection.
3) use std_loadsyms_modem.cmm script (present in common\tools\cmm\modem\) to load Modem Symbols.
4) type etm.on command in T32 window to enable Read/Write breakpoint
5) disable power collapse (refer to KB#00021944 for further detail)
set sleep_allow_low_power_modes=0 to disable Sleep once it reaches tmc_task(), otherwise JTAG lose connection and breakpoint.
Note: From 1020 build (FC release), step (2) is no longer needed for 8960 Q6 JTAG connection
Detail:
1) Specific T32 Software (Sep/2011) is needed. should have Proper licenses (Q6, ARM7) installed
2) You should set ISDB flag (refer to KB#00021765 for further detail). Otherwise T32 would refuse JTAG connection.
3) use std_loadsyms_modem.cmm script (present in common\tools\cmm\modem\) to load Modem Symbols.
4) type etm.on command in T32 window to enable Read/Write breakpoint
5) disable power collapse (refer to KB#00021944 for further detail)
set sleep_allow_low_power_modes=0 to disable Sleep once it reaches tmc_task(), otherwise JTAG lose connection and breakpoint.
Note: From 1020 build (FC release), step (2) is no longer needed for 8960 Q6 JTAG connection
Stabiltiy log collection through JTAG for MDM8200
Following is the procedure which can be used to collect JTAG dumps on MDM8200.
Details:
1. Start up the Trace32 sessions for ARM9 and QDSP62SW
2. Load the build and symbols (either 'do mjnload' or 'do jload')
3. Run the build ('do std_go' in the ARM9 Trace32)
After crash is seen:
4. Stop the ARM9 side in Trace32
5. Execute 'do std_savelogs' from the ARM9 Trace32 window.The save script should only be run once from the ARM9 side.
Details:
1. Start up the Trace32 sessions for ARM9 and QDSP62SW
2. Load the build and symbols (either 'do mjnload' or 'do jload')
3. Run the build ('do std_go' in the ARM9 Trace32)
After crash is seen:
4. Stop the ARM9 side in Trace32
5. Execute 'do std_savelogs' from the ARM9 Trace32 window.The save script should only be run once from the ARM9 side.
Information on JTAG mode pin selection with MDM8220/9x00 chipsets
In order to debug using daisy-chained T32 with MDM8220/9x00 chipsets, OEM needs to
ensure the mode pins in their board design are connected to get following state:
state
mode pin 0 high
mode pin 1 low
mode pin 2 high
mode pin 3 high
The reason for this setup is so that the daisy chain T32 configuration can be set through an internal register TLMM_INT_JTAG_CTRL,
which is determined by value specified in T32 shortcuts Qualcomm provides in folder:
\products\9X00\tools\t32\cmm_scripts
We recommend copying following shortcuts to your desktop to use:
- A9_Mode5
- Q6SW_Mode5
Other shortcuts in the folder are reserved.
How boot loader and modem images on eMMC device are protected?
Unlike NAND flash, for eMMC device there is no MPU to protect access to certain blocks/sectors in modem partitions. So how does eMMC device protect modem side partition?
For Qualcomm's platform with eMMC boot, it relies on eMMC-4.4 spec's POWER-ON-WRITE-PROTECT feature to protect modem side data. This feature (power-on-write-protect) is enabled and config'd at the end of OSBL, and when config'd, there is no way to switch those protected partition to become writable partition unless the eMMC device is reset.
Thus this feature can protect writing to protected modem partitions.
Pls note this feature (power-on-write-protect) appeared in eMMC spec since eMMC4.3+. Thus for eMMC device which is not compliant to eMMC4.3+ or higher, modem side data cannot not be protected. The power-on-write-protect commands sent to the sub eMMC4.3+ device are ignored and not respond.
Also in eMMC4.4 and beyond, there is one more pin defined (device reset) compared to eMMC4.3 or eMMC4.2 or spec with lower revisions. To prevent malicious SW or external HW to solely reset the eMMC device and make all partitions in eMMC devices into read/write state, it is required to bound the eMMC reset pin to system reset pin. In this way there is no way to solely reset the eMMC device from application processor side.
In summary, there are two requirements to utilize eMMC-4.4 power-on-write-protect feature to protect modem side data:
1. eMMC device must compliant to eMMC4.4 or higher. (Strictly speaking, it should be eMMC4.3+ or higher, but eMMC4.3+ is a transient spec and most vendors do not have production samples that only compliant to eMMC4.3+).
2. eMMC device's reset pin must be tied to system reset pin.
For Qualcomm's platform with eMMC boot, it relies on eMMC-4.4 spec's POWER-ON-WRITE-PROTECT feature to protect modem side data. This feature (power-on-write-protect) is enabled and config'd at the end of OSBL, and when config'd, there is no way to switch those protected partition to become writable partition unless the eMMC device is reset.
Thus this feature can protect writing to protected modem partitions.
Pls note this feature (power-on-write-protect) appeared in eMMC spec since eMMC4.3+. Thus for eMMC device which is not compliant to eMMC4.3+ or higher, modem side data cannot not be protected. The power-on-write-protect commands sent to the sub eMMC4.3+ device are ignored and not respond.
Also in eMMC4.4 and beyond, there is one more pin defined (device reset) compared to eMMC4.3 or eMMC4.2 or spec with lower revisions. To prevent malicious SW or external HW to solely reset the eMMC device and make all partitions in eMMC devices into read/write state, it is required to bound the eMMC reset pin to system reset pin. In this way there is no way to solely reset the eMMC device from application processor side.
In summary, there are two requirements to utilize eMMC-4.4 power-on-write-protect feature to protect modem side data:
1. eMMC device must compliant to eMMC4.4 or higher. (Strictly speaking, it should be eMMC4.3+ or higher, but eMMC4.3+ is a transient spec and most vendors do not have production samples that only compliant to eMMC4.3+).
2. eMMC device's reset pin must be tied to system reset pin.
How are GPIOs shared between modem and application processors in MSM7xxx?
GPIO_OWNER registers determine which processor owns the GPIO.
Detail: GPIO_OWNER registers determined which processor owns the GPIO. The bits in GPIO_OWNER registers are mapped to individual GPIOs. When the ownership register bit is set to 0, the corresponding GPIO is owned by modem processor. If the bit is set to 1, the GPIO is owned by application processor.
Write attempts without GPIO ownership are ignored. Read attempts without ownership always return 0. Once triggered, GPIO interrupts are routed to the appropriate owners.
Due to security reasons, GPIO_OWNER registers are not shadowed, which means that application processor cannot modify the GPIO_OWNER registers. All ownership setting is done by modem processor.
In addition, GPIO_PAGE and GPIO_CONFIG registers are not shadowed. As a result, even if the GPIO ownership is set to application processor, ARM11 cannot change the alternative function setting of a GPIO. Configuring GPIO alternative function can only be done by modem processor.
For example, when application processor is ready to enter sleep, it will inform the modem processor to take over all the GPIOs. Modem processor switches all GPIOs by writing 0s to the GPIO_OWNER registers before putting application processor into sleep. This allows modem processor to carry out GPIO reconfiguration during sleep, and handle all GPIO interrupts when application processor is in sleep. When application processor wakes up, modem processor restores GPIO_OWNER registers to its original settings.
Detail: GPIO_OWNER registers determined which processor owns the GPIO. The bits in GPIO_OWNER registers are mapped to individual GPIOs. When the ownership register bit is set to 0, the corresponding GPIO is owned by modem processor. If the bit is set to 1, the GPIO is owned by application processor.
Write attempts without GPIO ownership are ignored. Read attempts without ownership always return 0. Once triggered, GPIO interrupts are routed to the appropriate owners.
Due to security reasons, GPIO_OWNER registers are not shadowed, which means that application processor cannot modify the GPIO_OWNER registers. All ownership setting is done by modem processor.
In addition, GPIO_PAGE and GPIO_CONFIG registers are not shadowed. As a result, even if the GPIO ownership is set to application processor, ARM11 cannot change the alternative function setting of a GPIO. Configuring GPIO alternative function can only be done by modem processor.
For example, when application processor is ready to enter sleep, it will inform the modem processor to take over all the GPIOs. Modem processor switches all GPIOs by writing 0s to the GPIO_OWNER registers before putting application processor into sleep. This allows modem processor to carry out GPIO reconfiguration during sleep, and handle all GPIO interrupts when application processor is in sleep. When application processor wakes up, modem processor restores GPIO_OWNER registers to its original settings.
MDM9x15 build environment (L4 running on Apps processor)
For 9x15, there are 3 separate images, modem/app/boot, the build environments are shown below:
| APSS | apps_proc\build\ms | RVCT 41P514 | Python 2.5.2 | |||
| MPSS | modem_proc\build\ms | Hexagon 3.0.05 | Python 2.5.2 | |||
| Boot Images | boot_images\core\bsp\build | RVCT 41P514 | Python 2.5.2 |
How does Proximity Sensor Data get measured and reported by DSPS?
On the 8960-based design, the DSPS streams the Proximity sensor data @ 5Hz and in parallel does the Proximity threshold detection (Near Vs. Far). Only when the state changes (Near-Far and vice-versa) does DSPS respond back to the Application which would have registered for such a callback earlier. This allows for better power optimization in that the Application does not need to be monitoring the streaming Proximity data as its being read/processed by DSPS so the AP can be power-collapsed during that time. DSPS currently does not support proximity sensor interrupt.
Reference Source Code File: sns_dd_alsprx.c
For more detailed description of the scenario, here is a call flow sequence for Proximity sensor data processing:
Assume the device has received a phone call.
1. Phone call is active
2. Android Power Manager requests proximity data through HAL
3. Sensor HAL (AP) sends proximity threshold detect request to DSPS (SAM)
4. SAM (DSPS) receives proximity threshold detect request and sends 5Hz proximity data request message to SMGR (also on DSPS)
5. SMGR (DSPS) receives proximity data request, starts reading proximity data at 5Hz, and returns data to SAM (DSPS)
6. SAM (DSPS) calculates near / far based on proximity threshold
7. If distance changes from near to far or vice versa, SAM (DSPS) sends proximity change indication message back to HAL (AP)
Note: If there's no change in distance, no proximity change indication message is sent from DSPS to AP
8. When Sensor HAL (AP) receives proximity change indication message, it returns near / far indication to Android Power Manager
9. Android Power Manager will turn off screen if proximity indicates near and AP will go into power collapse
10. Go to step 5
Reference Source Code File: sns_dd_alsprx.c
For more detailed description of the scenario, here is a call flow sequence for Proximity sensor data processing:
Assume the device has received a phone call.
1. Phone call is active
2. Android Power Manager requests proximity data through HAL
3. Sensor HAL (AP) sends proximity threshold detect request to DSPS (SAM)
4. SAM (DSPS) receives proximity threshold detect request and sends 5Hz proximity data request message to SMGR (also on DSPS)
5. SMGR (DSPS) receives proximity data request, starts reading proximity data at 5Hz, and returns data to SAM (DSPS)
6. SAM (DSPS) calculates near / far based on proximity threshold
7. If distance changes from near to far or vice versa, SAM (DSPS) sends proximity change indication message back to HAL (AP)
Note: If there's no change in distance, no proximity change indication message is sent from DSPS to AP
8. When Sensor HAL (AP) receives proximity change indication message, it returns near / far indication to Android Power Manager
9. Android Power Manager will turn off screen if proximity indicates near and AP will go into power collapse
10. Go to step 5
List of Plan of Record (PoR) Sensor Parts for QCT FLUID Platform with MSM8960
Here's list of PoR Sensors:
- Accelerometer: LIS3DH (ST Microelectronics)
- Magnetometer: AK8975C (Asahi Kasei Microelectronics (AKM))
- Mag calibration library - from AKM
- Gryoscope: MPU3050 from InvenSense
- ALS/Proximity: ISL29028 from Intersil
- Pressure: BMP085 from Bosch
For integration sensors that are not part of the list above, OEMs can refer to following document to integrate the respective drivers with DSPS Device Driver Framework (DDF):
80-N7635-1: Dedicated Sensor Processor Subsystem (DSPS) New Sensor Driver Integration Guide
Here's list of PoR Sensors:
- Accelerometer: LIS3DH (ST Microelectronics)
- Magnetometer: AK8975C (Asahi Kasei Microelectronics (AKM))
- Mag calibration library - from AKM
- Gryoscope: MPU3050 from InvenSense
- ALS/Proximity: ISL29028 from Intersil
- Pressure: BMP085 from Bosch
For integration sensors that are not part of the list above, OEMs can refer to following document to integrate the respective drivers with DSPS Device Driver Framework (DDF):
80-N7635-1: Dedicated Sensor Processor Subsystem (DSPS) New Sensor Driver Integration Guide
- Accelerometer: LIS3DH (ST Microelectronics)
- Magnetometer: AK8975C (Asahi Kasei Microelectronics (AKM))
- Mag calibration library - from AKM
- Gryoscope: MPU3050 from InvenSense
- ALS/Proximity: ISL29028 from Intersil
- Pressure: BMP085 from Bosch
For integration sensors that are not part of the list above, OEMs can refer to following document to integrate the respective drivers with DSPS Device Driver Framework (DDF):
80-N7635-1: Dedicated Sensor Processor Subsystem (DSPS) New Sensor Driver Integration Guide
Here's list of PoR Sensors:
- Accelerometer: LIS3DH (ST Microelectronics)
- Magnetometer: AK8975C (Asahi Kasei Microelectronics (AKM))
- Mag calibration library - from AKM
- Gryoscope: MPU3050 from InvenSense
- ALS/Proximity: ISL29028 from Intersil
- Pressure: BMP085 from Bosch
For integration sensors that are not part of the list above, OEMs can refer to following document to integrate the respective drivers with DSPS Device Driver Framework (DDF):
80-N7635-1: Dedicated Sensor Processor Subsystem (DSPS) New Sensor Driver Integration Guide
How to measure the DSPS sensor reset time in MSM8960
when you need to get the reset time of DSPS sensor as follows. (add 1, 2,3)
dsps_proc/core/sensors/smgr/src/common/sns_smgr_sol.c
void sns_smgr_reset_sensor(smgr_sensor_s *sensor_ptr)
{
sns_ddf_status_e reset_status=SNS_DDF_EDEVICE;
sns_ddf_powerstate_e set_data;
<add 1 - start>
uint32_t start_ts;
<add 1 - end>
sns_hw_set_qup_clk(true);
set_data = SNS_DDF_POWERSTATE_ACTIVE;
sensor_ptr->driver_status = sns_smgr_set_attr( sensor_ptr->drv_fn_ptr,
sensor_ptr->dd_handle_ptr,
SNS_DDF_SENSOR__ALL,
SNS_DDF_ATTRIB_POWER_STATE,
&set_data );
SNS_PRINTF_STRING_ID_HIGH_3(SNS_DBG_MOD_DSPS_SMGR,
DBG_SMGR_GENERIC_STRING3,
SNS_DDF_POWERSTATE_ACTIVE,
sensor_ptr->const_ptr->sensor_id, sensor_ptr->driver_status);
/* Increased delay between set active power and sensor reset for MPU3050 configuring interrupt
during reset, MPU3050 starts working at 600us ( not at500us ), MPU6050 needs 200us */
SMGR_DELAY_US(800);
<add 2 - start> 3000, 3001 - Red numbers is just to make it easy to find using value
SNS_PRINTF_STRING_ID_HIGH_3(SNS_DBG_MOD_DSPS_SMGR,
DBG_SMGR_GENERIC_STRING3,
3000, sensor_ptr->sensor_id, sns_em_get_timestamp() );
start_ts = sns_em_get_timestamp();
<add 2 - end>
reset_status= sensor_ptr->drv_fn_ptr->reset(sensor_ptr->dd_handle_ptr);
<add 3 - start>
SNS_PRINTF_STRING_ID_HIGH_3(SNS_DBG_MOD_DSPS_SMGR,
DBG_SMGR_GENERIC_STRING3,
3001, start_ts, sns_em_get_timestamp());
<add 3 - end>
<snip>
...
}
then rebuild dsps image and load to device.
and follow these steps
1. connect QXDM and getting the QXDM log.
2. start QSensorTest App.
3. executes the sensor of desired time measurement
4. stop
5. repeat step 3 and step 4 several times
6. search 3000, 3001 in the log then you can find time tick value
7. Calculation : (before reset tick - after reset tick) * 30.51
ps) DSPS one tick is 30.51us
ex) before tick after reset tick time tick Time (us)
15185300 15185860 560 17085.60
15405717 15406275 558 17024.58
15405717 15406275 558 17024.58
Can we have 3D graphics user interface running concurrently with Audio_LP aDSP image in MSM7k?
The 7K MSM has one large internal memory (IMEM) of 256Kbytes dedicated for usage by the graphics core. It is designed to allow this memory to be mapped for other uses when the graphics does not need this memory.
The reason for existence of this RAM in the MSM is to provide the Graphics (higher priority) and DSP cores with the fastest access speed such that these cores can meet their performance requirements in the MSM as a system.
The Audio_LP aDSP image needs the 128Kbytes of IMEM to function and meet it's power and performance needs. However, if the 3D graphics user interface is previously running, the IMEM is already occupied, thereby halting the Audio_LP aDSP image from functioning.
The only alternative is to tear-down the 3D graphics user interface, free up IMEM usage, and then load the Audio_LP aDSP image.
The reason for existence of this RAM in the MSM is to provide the Graphics (higher priority) and DSP cores with the fastest access speed such that these cores can meet their performance requirements in the MSM as a system.
The Audio_LP aDSP image needs the 128Kbytes of IMEM to function and meet it's power and performance needs. However, if the 3D graphics user interface is previously running, the IMEM is already occupied, thereby halting the Audio_LP aDSP image from functioning.
The only alternative is to tear-down the 3D graphics user interface, free up IMEM usage, and then load the Audio_LP aDSP image.
Do MSM7630/8655 DDR ctlr issue 'ZQ initialization' (MRW10) to LPDDR2 during init sequence?
Yes. MSM8655-0 DDR controller configure 'ZQ initialization' (MRW10) as part of "hardware ddr init". "hardware ddr init" is hardware triggered DDR initialization which can be trigger by writing bit 0 of EBI0_SDRAM_INIT_CTRL.
In HAL_BOOT_DDR.c, one can see the below part. This is just one register write, but internally DDR ctlr issue 'ZQ initialization' to DDR2 device.
One of requirements is to send MR1/2 after "ZQ initialization". That can be also confirmed in HAL_BOOT_DDR.c, because MR1/2 are configured after the below code line in HAL_BOOT_DDR.c.
HAL_SDRAM_HW_Init()
{
< code snippet >
/* Trigger the Hardware Initialization flow. */
BOOT_HWIO_OUT(EBI0_SDRAM_INIT_CTRL, offset, 0x0001);
}
The below is the reference from DDR controller design document. The same can be found from LPDDR2 datasheet too.
-----------------------------------------------------------------------------------------------
ZQ Calibration:
After tINIT5, an MRW ZQ Initialization Calibration command may be issued to the memory
(MR10). For LPDDR2 devices which do not support the ZQ Calibration command, this
command shall be ignored. This command is used to calibrate the LPDDR2 output drivers
(RON) over process, voltage, and temperature. In systems in which more than one LPDDR2
device exists on the same bus, the controller must not overlap ZQ Calibration commands. The
device is ready for normal operation after tZQINIT.
-----------------------------------------------------------------------------------------------
In HAL_BOOT_DDR.c, one can see the below part. This is just one register write, but internally DDR ctlr issue 'ZQ initialization' to DDR2 device.
One of requirements is to send MR1/2 after "ZQ initialization". That can be also confirmed in HAL_BOOT_DDR.c, because MR1/2 are configured after the below code line in HAL_BOOT_DDR.c.
HAL_SDRAM_HW_Init()
{
< code snippet >
/* Trigger the Hardware Initialization flow. */
BOOT_HWIO_OUT(EBI0_SDRAM_INIT_CTRL, offset, 0x0001);
}
The below is the reference from DDR controller design document. The same can be found from LPDDR2 datasheet too.
-----------------------------------------------------------------------------------------------
ZQ Calibration:
After tINIT5, an MRW ZQ Initialization Calibration command may be issued to the memory
(MR10). For LPDDR2 devices which do not support the ZQ Calibration command, this
command shall be ignored. This command is used to calibrate the LPDDR2 output drivers
(RON) over process, voltage, and temperature. In systems in which more than one LPDDR2
device exists on the same bus, the controller must not overlap ZQ Calibration commands. The
device is ready for normal operation after tZQINIT.
-----------------------------------------------------------------------------------------------
5 new partitions usage on MDM9x15
CACHE : Contains the update package which is downloaded from server. Also holds the log file for recovery
RECOVERY : Holds the recovery boot image(When updating the system we boot into recovery mode by using the boot image stored in this partition
RECOVERYFS : Holds recovery filesystem(including the recovery module that actually runs goes and updates the system). The recovery.img in the RECOVERY partition boots into this rootfs.
FOTA : After the update package is downloaded from the server it is saved into the cache partition. After that the userspace app that does the download writes a special cookie into the FOTA partition. This cookie tells the bootloaders to take the necessary steps to boot into recovery mode
MISC : Not really used in 9x15
RECOVERY : Holds the recovery boot image(When updating the system we boot into recovery mode by using the boot image stored in this partition
RECOVERYFS : Holds recovery filesystem(including the recovery module that actually runs goes and updates the system). The recovery.img in the RECOVERY partition boots into this rootfs.
FOTA : After the update package is downloaded from the server it is saved into the cache partition. After that the userspace app that does the download writes a special cookie into the FOTA partition. This cookie tells the bootloaders to take the necessary steps to boot into recovery mode
MISC : Not really used in 9x15
How to modify drive strength driven by LPDDR2 device on M8660 target ?
The default DDR driver of M8660 target doesn't provide MR3 therefore the reset default setting of MR3 which is typically 40ohm is used in LPDDR2 device.
If need to adjust DS of memory device, the following will help.
Details: If DS is too strong, plz set a bigger R for mr_wdata. Otherwise a less R would help to get a higher DS.
\modem_proc\core\boot\ddr\hal\target\msm8660\src\HAL_BOOT_DDR.c
void HAL_SDRAM_Update_MR_Settings(SDRAM_INTERFACE interface_name, SDRAM_CHIPSELECT chip_select)
<at the end of this function>
/* configure MR3 only for EBI1 */
if(interface_name == SDRAM_INTERFACE_1)
{
/*
Configure the I/O Configuration 3 Mode Register in the LPDDR2 device using the following
sequence. This sets attributes like read and write latency.
MR3
// DS Write-only OP<3:0>
// 0000B: reserved
// 0001B: 34.3-ohm typical
// 0010B: 40-ohm typical (default)
// 0011B: 48-ohm typical
// 0100B: 60-ohm typical
// 0101B: reserved for 68.6-ohm typical
// 0110B: 80-ohm typical
// 0111B: 120-ohm typical (optional)
// All others: reserved
*/
/* Set to MR3 */
BOOT_HWIO_OUTM(EBI1_CH0_DDR_MR_CNTL_WDATA, offset,
HWIO_FMSK(EBI1_CH0_DDR_MR_CNTL_WDATA, MR_ADDR),
0x3 << HWIO_SHFT(EBI1_CH0_DDR_MR_CNTL_WDATA, MR_ADDR));
/* a smaller RON, a stronger DS and a bigger ROM, a weaker DS */
mr_wdata = 0x1;
/* write the wdata to register */
BOOT_HWIO_OUTM(EBI1_CH0_DDR_MR_CNTL_WDATA, offset, HWIO_FMSK(EBI1_CH0_DDR_MR_CNTL_WDATA, MR_WDATA), mr_wdata);
/*
Set the field "MRW" in DDR_MR_CNTL_WDATA to indicate that this is a mode register
write command.
This also triggers the actual write.
*/
BOOT_HWIO_OUTM(EBI1_CH0_DDR_MR_CNTL_WDATA, offset,
HWIO_FMSK(EBI1_CH0_DDR_MR_CNTL_WDATA, MRW),
HWIO_FMSK(EBI1_CH0_DDR_MR_CNTL_WDATA, MRW));
/* Poll for Mode Register Write Complete */
while(BOOT_HWIO_INM(EBI1_CH0_DDR_MR_CNTL_WDATA, offset, HWIO_FMSK(EBI1_CH0_DDR_MR_CNTL_WDATA, MRW)))
{}
/* Wait at least 5 DDR1x Clock Cycles*/
HAL_SDRAM_DDR_Wait(5, 0);
}
If need to adjust DS of memory device, the following will help.
Details: If DS is too strong, plz set a bigger R for mr_wdata. Otherwise a less R would help to get a higher DS.
\modem_proc\core\boot\ddr\hal\target\msm8660\src\HAL_BOOT_DDR.c
void HAL_SDRAM_Update_MR_Settings(SDRAM_INTERFACE interface_name, SDRAM_CHIPSELECT chip_select)
<at the end of this function>
/* configure MR3 only for EBI1 */
if(interface_name == SDRAM_INTERFACE_1)
{
/*
Configure the I/O Configuration 3 Mode Register in the LPDDR2 device using the following
sequence. This sets attributes like read and write latency.
MR3
// DS Write-only OP<3:0>
// 0000B: reserved
// 0001B: 34.3-ohm typical
// 0010B: 40-ohm typical (default)
// 0011B: 48-ohm typical
// 0100B: 60-ohm typical
// 0101B: reserved for 68.6-ohm typical
// 0110B: 80-ohm typical
// 0111B: 120-ohm typical (optional)
// All others: reserved
*/
/* Set to MR3 */
BOOT_HWIO_OUTM(EBI1_CH0_DDR_MR_CNTL_WDATA, offset,
HWIO_FMSK(EBI1_CH0_DDR_MR_CNTL_WDATA, MR_ADDR),
0x3 << HWIO_SHFT(EBI1_CH0_DDR_MR_CNTL_WDATA, MR_ADDR));
/* a smaller RON, a stronger DS and a bigger ROM, a weaker DS */
mr_wdata = 0x1;
/* write the wdata to register */
BOOT_HWIO_OUTM(EBI1_CH0_DDR_MR_CNTL_WDATA, offset, HWIO_FMSK(EBI1_CH0_DDR_MR_CNTL_WDATA, MR_WDATA), mr_wdata);
/*
Set the field "MRW" in DDR_MR_CNTL_WDATA to indicate that this is a mode register
write command.
This also triggers the actual write.
*/
BOOT_HWIO_OUTM(EBI1_CH0_DDR_MR_CNTL_WDATA, offset,
HWIO_FMSK(EBI1_CH0_DDR_MR_CNTL_WDATA, MRW),
HWIO_FMSK(EBI1_CH0_DDR_MR_CNTL_WDATA, MRW));
/* Poll for Mode Register Write Complete */
while(BOOT_HWIO_INM(EBI1_CH0_DDR_MR_CNTL_WDATA, offset, HWIO_FMSK(EBI1_CH0_DDR_MR_CNTL_WDATA, MRW)))
{}
/* Wait at least 5 DDR1x Clock Cycles*/
HAL_SDRAM_DDR_Wait(5, 0);
}
5/24/2012
What tools are available for Adreno?
Adreno Profiler
Adreno Profiler is a PC tool for detailed performance analysis of 3D graphics applications running on Qualcomm's Adreno GPUs.
The tool connects to a device via USB and provides such information as:
GPU and system level performance metrics
OpenGL ES API call tracing and emulation
Real time driver overrides
Adreno Profiler can be used by 3D content developers to test, debug, and profile embedded 3D games and applications on retail handsets without having to change the application.
Supported chipsets and platforms as of Mar. 2010 are the followings.
WindowsMobile 6.1 and 6.5 � Adreno130 (MSM7x01), Adreno200 (MSM7x27, QSD8x50)
Linux Android Donut � Adreno200 (MSM7x27, QSD8x50)
Linux Android Éclair � Adreno200 (MSM7x27, QSD8x50), Adreno205 (MSM7x30)
Linux LE � Adreno200 (QSD8x50)
BMP � Adreno130 (MSM7x01)
Adreno SDK
The Adreno SDK provides samples, tutorials, documentation, headers and libraries, a PC OpenGL ES emulator, and other miscellaneous tools for developing for Qualcomm's Adreno GPUs.
Adreno SDK includes
Unified Emulator (desktop support for OpenGL ES 2.0 and 1.x)
More than 40 samples and tutorials
An advanced demo, including source code
Extensive documentation
Texture Converter, a library for texture compression and conversion
Qstrip, Qualcomm's triangle stripping library
Offline shader compiler
Other miscellaneous tools
How to get this tool?
The tool can be released to the licensee OEMs individually upon request. Please create a Case requesting installers and than Customer Engineering will support to get it released.
Or, it is also downloadable from 'TOOLS & DOWNLOAD' page at Qualcomm Developer Network after aquiring an account.
Other references
Application Developers' Guide for Adreno200 (80-VT425-1), Section 3.1 has an introduction to the tools.
Adreno Profiler is a PC tool for detailed performance analysis of 3D graphics applications running on Qualcomm's Adreno GPUs.
The tool connects to a device via USB and provides such information as:
GPU and system level performance metrics
OpenGL ES API call tracing and emulation
Real time driver overrides
Adreno Profiler can be used by 3D content developers to test, debug, and profile embedded 3D games and applications on retail handsets without having to change the application.
Supported chipsets and platforms as of Mar. 2010 are the followings.
WindowsMobile 6.1 and 6.5 � Adreno130 (MSM7x01), Adreno200 (MSM7x27, QSD8x50)
Linux Android Donut � Adreno200 (MSM7x27, QSD8x50)
Linux Android Éclair � Adreno200 (MSM7x27, QSD8x50), Adreno205 (MSM7x30)
Linux LE � Adreno200 (QSD8x50)
BMP � Adreno130 (MSM7x01)
Adreno SDK
The Adreno SDK provides samples, tutorials, documentation, headers and libraries, a PC OpenGL ES emulator, and other miscellaneous tools for developing for Qualcomm's Adreno GPUs.
Adreno SDK includes
Unified Emulator (desktop support for OpenGL ES 2.0 and 1.x)
More than 40 samples and tutorials
An advanced demo, including source code
Extensive documentation
Texture Converter, a library for texture compression and conversion
Qstrip, Qualcomm's triangle stripping library
Offline shader compiler
Other miscellaneous tools
How to get this tool?
The tool can be released to the licensee OEMs individually upon request. Please create a Case requesting installers and than Customer Engineering will support to get it released.
Or, it is also downloadable from 'TOOLS & DOWNLOAD' page at Qualcomm Developer Network after aquiring an account.
Other references
Application Developers' Guide for Adreno200 (80-VT425-1), Section 3.1 has an introduction to the tools.
How to capture framebuffer in Android
Answer : It can be done by accessing /dev/graphics/fb0.
1. Using adb command.
>adb shell
#cat /dev/graphics/fb0 > /data/dump
#exit
>adb pull /data/dump
This command dumps the frame buffer data in raw format (ex. RGB565) into the file.
2. Similar method can be adapted in source code level.
1) Open the device
fb_fd = open("/dev/graphics/fb0", O_RDONLY)
2) Get the framebuffer pointer
fb_ptr = mmap(0, fb_size_total, PROT_READ, MAP_SHARED, fb_fd, 0)
3) Get the frame buffer offset
ioctl(fb_fd, FBIOGET_VSCREENINFO, &vinfo)
page_offset = fb_width * vinfo.yoffset * bytes_per_pixel
4) Copy frame buffer to user memory.
memcpy(fb_data, fb_ptr + page_offset, fb_size)
5) Unmap framebuffer.
munmap(fb_ptr, fb_size_total)
1. Using adb command.
>adb shell
#cat /dev/graphics/fb0 > /data/dump
#exit
>adb pull /data/dump
This command dumps the frame buffer data in raw format (ex. RGB565) into the file.
2. Similar method can be adapted in source code level.
1) Open the device
fb_fd = open("/dev/graphics/fb0", O_RDONLY)
2) Get the framebuffer pointer
fb_ptr = mmap(0, fb_size_total, PROT_READ, MAP_SHARED, fb_fd, 0)
3) Get the frame buffer offset
ioctl(fb_fd, FBIOGET_VSCREENINFO, &vinfo)
page_offset = fb_width * vinfo.yoffset * bytes_per_pixel
4) Copy frame buffer to user memory.
memcpy(fb_data, fb_ptr + page_offset, fb_size)
5) Unmap framebuffer.
munmap(fb_ptr, fb_size_total)
5/19/2012
Use dumpsys to collect HDMI register values in run-time
In order to debug HDMI, users can mount debugfs and dump register values for their need.
=====The following is the way to mount debugfs=====
# adb shell
# mkdir /data/debug
mkdir /data/debug
# mount -t debugfs debugfs /data/debug
mount -t debugfs debugfs /data/debug
=====The following is the way to specify hdmi registers to dump=====
# cd /data/debug/hdmi
cd /data/debug/hdmi
# echo [offset] [# of consecutive registers] > off
# cat reg
e.g. # echo 0 4 > off
echo 0 4 > off
# cat reg
cat reg
0xda8a4000: 00000007 00000000 00000000 00000000 (Then you will see 4 registers dump beginning with hdmi register 0x0000, i.e. HDMI_CTRL.)
=====The following is the way to mount debugfs=====
# adb shell
# mkdir /data/debug
mkdir /data/debug
# mount -t debugfs debugfs /data/debug
mount -t debugfs debugfs /data/debug
=====The following is the way to specify hdmi registers to dump=====
# cd /data/debug/hdmi
cd /data/debug/hdmi
# echo [offset] [# of consecutive registers] > off
# cat reg
e.g. # echo 0 4 > off
echo 0 4 > off
# cat reg
cat reg
0xda8a4000: 00000007 00000000 00000000 00000000 (Then you will see 4 registers dump beginning with hdmi register 0x0000, i.e. HDMI_CTRL.)
How the Scropion clock is configured during boot stage?
If you are working on the 8x60 LK boot-loader, you might note the Scoprion clock is no longer configured in LK - acpu_clock_init() anymore, it's because boot architecture in 8x60 platfrom is different from previous platform (i.e 7x30/8x55), in 8x60 platfomr the Scorpion is start to run before the modem processor.
Basically, the Scorpion clock is controlled by the SCSS_CLK_CTL and SCSS_CLK_SEL register, after the system boot up (reset), by default the Scorpion clock is tighted with AXI (EBI1) speed. In current 8x60 software design the Scorpion clock is configured in SBL1 (RPM bootloader), SBL2(Scorpion bootloader), and SBL3 (Scorpion bootloader), this solution will show you where the Scorpion clock is set and what speed of Scorpion at that point.
SBL1:
After calling clk_regime_rpm_init_boot_rpmsbl(), the AXI is configured to 128MHz, so the Scorpion clock is 128MHz.
SBL2:
In clk_regime_apps_init_boot(), the Scorpion clock is configured from 128MHz to 524MHz, the detailed are : 128MHz (AXI Speed) -> 262MHz (AXI Speed) -> 384MHz (PLL8 -- 384MHz / 1) -> 524MHz (PLL11 -- 1048MHz / 2).
SBL3:
After calling the clk_regime_apps_switch_acpu_clk_core(), the Scorpion clock is 750MHz (PLL9 -- 1500MHz / 2).
Basically, the Scorpion clock is controlled by the SCSS_CLK_CTL and SCSS_CLK_SEL register, after the system boot up (reset), by default the Scorpion clock is tighted with AXI (EBI1) speed. In current 8x60 software design the Scorpion clock is configured in SBL1 (RPM bootloader), SBL2(Scorpion bootloader), and SBL3 (Scorpion bootloader), this solution will show you where the Scorpion clock is set and what speed of Scorpion at that point.
SBL1:
After calling clk_regime_rpm_init_boot_rpmsbl(), the AXI is configured to 128MHz, so the Scorpion clock is 128MHz.
SBL2:
In clk_regime_apps_init_boot(), the Scorpion clock is configured from 128MHz to 524MHz, the detailed are : 128MHz (AXI Speed) -> 262MHz (AXI Speed) -> 384MHz (PLL8 -- 384MHz / 1) -> 524MHz (PLL11 -- 1048MHz / 2).
SBL3:
After calling the clk_regime_apps_switch_acpu_clk_core(), the Scorpion clock is 750MHz (PLL9 -- 1500MHz / 2).
[msm8x60] How to increase MAX deivce count for sound path?
If you have added many device in snddev_data_timpani.c.
some time its count can be over than 30.
but when use uses new device list, only 30 devices are presented.
in this case, MAX_DEVICE_COUNT was already defined in AudioHardware.cpp (8x60 case only)
so If customer uses many device(in this case over the 30), please change the defined value in AudioHardware.cpp as below.
from
#define MAX_DEVICE_COUNT 30
to
#define MAX_DEVICE_COUNT 100
some time its count can be over than 30.
but when use uses new device list, only 30 devices are presented.
in this case, MAX_DEVICE_COUNT was already defined in AudioHardware.cpp (8x60 case only)
so If customer uses many device(in this case over the 30), please change the defined value in AudioHardware.cpp as below.
from
#define MAX_DEVICE_COUNT 30
to
#define MAX_DEVICE_COUNT 100
Why Cell Broadcast channel 4370 can't be delete from channel list ?
[Question] : Why Cell Broadcast channel 4370 can't be delete from channel list ?
[Answer] :
CB 4370 (WMS_GW_CB_SRV_ID_CMAS_MSGID1) is protected.
You can reference wms.h
/** Commercial Mobile Alert System CBS message identifier for Presidential-level alerts.\ The MMI cannot
set this. *
*/
#define WMS_GW_CB_SRV_ID_CMAS_MSGID1 4370
For CMAS, you can reference solution #00015702 for more detail.
So this is normal you can't delete cell broadcast channel 4370.
[Answer] :
CB 4370 (WMS_GW_CB_SRV_ID_CMAS_MSGID1) is protected.
You can reference wms.h
/** Commercial Mobile Alert System CBS message identifier for Presidential-level alerts.\ The MMI cannot
set this. *
*/
#define WMS_GW_CB_SRV_ID_CMAS_MSGID1 4370
For CMAS, you can reference solution #00015702 for more detail.
So this is normal you can't delete cell broadcast channel 4370.
How is the client ever notified of a non-provisioning session like ISIM?
Question -
ISIM is a non-provisioning app that is not required for camping purposes.
How is the client ever notified of a non-provisioning session like ISIM?
Card status indications in UIM show up as unknown because there is not ISIM app type defined in mmgsdi_app_enum_type. Can you please check AMSS implementation?
Answer -
The structure mmgsdi_aid_type contains the aid (mmgsdi_static_data_type) in addition to the app type. In case of ISIM, the app type is going to be MMGSDI_APP_UNKNOWN and the client needs to check the AID to see if it's a ISIM or not.
The value of the ISIM AID starts with 0xA0000000871004, as per 101.220.
ISIM is a non-provisioning app that is not required for camping purposes.
How is the client ever notified of a non-provisioning session like ISIM?
Card status indications in UIM show up as unknown because there is not ISIM app type defined in mmgsdi_app_enum_type. Can you please check AMSS implementation?
Answer -
The structure mmgsdi_aid_type contains the aid (mmgsdi_static_data_type) in addition to the app type. In case of ISIM, the app type is going to be MMGSDI_APP_UNKNOWN and the client needs to check the AID to see if it's a ISIM or not.
The value of the ISIM AID starts with 0xA0000000871004, as per 101.220.
How to integrate for DivX playback and DivX DRM on Android
Step 1
- Please download the sources from the CRM build for mm-parser and mm-parser-bin.
Step 2
- OEMs should compile sources for mm-parser and mm-parser-bin which will generate "libmmaprser.so" and "libmmparser_divxdrmlib.so" (will be available in out directory).
Step 3
- Replacing libmmparser_divxdrmlib.so and compile DivX DRM source code, this is required only if you are replacing the default DivX DRM library from Qualcomm to the library provided by DivX for certification.
Please generate the library with the same name as default DRM library "libmmparser_divxdrmlib.so " and rebuild the mm-parser and mm-parser-bin.
Step 2.1 - mm-parser source:
- location: \vendor\qcom\proprietary\mm-parser
- OEM needs to build the mm-parser library "libmmparser.so" for which source is provided in the above location.
build.mk: will generate libmmparser.so
build_common.mk: DRM and links to DivXDRMlib.
Step 2.2 - Qualcomm supports the AVI parser for DivX playback in the Gingerbread and Honeycomb builds.
AVI parser Source location:
vendor\qcom\proprietary\mm-parser\main\AVIParserLib
Step 2.3 - DivxDRMLib(DivX DRM):
- location: \vendor\qcom\proprietary\mm-parser-bin\DivxDRMLib\<target>
- OEM needs to build the default DivXDrm library " libmmparser_divxdrmlib.so" for which source is provided in the above location.
- The DivXDrm library (libmmparser_divxdrmlib.so) is a separate binary to the libmmparser.so. The reason for this is that the DivXDrm library that we ship to customers is just a reference implementation, which is functional enough for testing but is to be replaced by the library provided by DivX in a final product.
- Please download the sources from the CRM build for mm-parser and mm-parser-bin.
Step 2
- OEMs should compile sources for mm-parser and mm-parser-bin which will generate "libmmaprser.so" and "libmmparser_divxdrmlib.so" (will be available in out directory).
Step 3
- Replacing libmmparser_divxdrmlib.so and compile DivX DRM source code, this is required only if you are replacing the default DivX DRM library from Qualcomm to the library provided by DivX for certification.
Please generate the library with the same name as default DRM library "libmmparser_divxdrmlib.so " and rebuild the mm-parser and mm-parser-bin.
Step 2.1 - mm-parser source:
- location: \vendor\qcom\proprietary\mm-parser
- OEM needs to build the mm-parser library "libmmparser.so" for which source is provided in the above location.
build.mk: will generate libmmparser.so
build_common.mk: DRM and links to DivXDRMlib.
Step 2.2 - Qualcomm supports the AVI parser for DivX playback in the Gingerbread and Honeycomb builds.
AVI parser Source location:
vendor\qcom\proprietary\mm-parser\main\AVIParserLib
Step 2.3 - DivxDRMLib(DivX DRM):
- location: \vendor\qcom\proprietary\mm-parser-bin\DivxDRMLib\<target>
- OEM needs to build the default DivXDrm library " libmmparser_divxdrmlib.so" for which source is provided in the above location.
- The DivXDrm library (libmmparser_divxdrmlib.so) is a separate binary to the libmmparser.so. The reason for this is that the DivXDrm library that we ship to customers is just a reference implementation, which is functional enough for testing but is to be replaced by the library provided by DivX in a final product.
Changes to MVS interface for EVRC-NW (SO-73 vocoder) support
MVS should provide enhanced/new frame info type to support 1/8th rate non-critical frame type.
MVS defines new vocoder mode as MVS_MODE_EVRC_NW
Following are the new definitions added for MVS APIs
1.1 New MVS Definitions
Following are the new values defined in the corresponding enums to support SO-73
mvs_mode_type: MVS_MODE_4GV_NW is used to denote SO-73 vocoder whereever mvs_mode_type is used. eg: mvs_enable() API should use the above enum value for SO-73.
typedef enum {
MVS_MODE_NONE,
MVS_MODE_IS733, /* QCELP-13k */
MVS_MODE_IS127, /* EVRC-8k */
MVS_MODE_4GV_NB, /* 4GV narrow band */
MVS_MODE_4GV_WB, /* 4GV wide band */
MVS_MODE_AMR, /* Adaptive multi-rate */
MVS_MODE_EFR, /* Enhanced full rate */
MVS_MODE_FR, /* Full rate */
MVS_MODE_HR, /* Half rate */
MVS_MODE_LINEAR_PCM, /* enable/disable PCM interface */
MVS_MODE_G711, /* G.711 vocoder */
MVS_MODE_G723, /* G.723 vocoder */
MVS_MODE_PCM, /* PCM vocoder */
MVS_MODE_AMR_WB, /* AMR-WB vocoder */
MVS_MODE_G729A, /* G729A vocoder */
MVS_MODE_G711A, /* G711A vocoder */
MVS_MODE_G722, /* G722 vocoder */
MVS_MODE_4GV_NW, /* 4GV narrowband-wideband */
MVS_MODE_MAX,
MVS_MODE_32BIT_DUMMY = 0x7FFFFFFF
} mvs_mode_type;
mvs_voc_rate_type: MVS_VOC_8_RATE_NONCRITICAL signifies that, the encoded packet associated with, is an Non-critical eighth rate frame.
typedef enum {
MVS_VOC_0_RATE, /* blank frame */
MVS_VOC_8_RATE, /* 1/8 rate */
MVS_VOC_4_RATE, /* 1/4 rate */
MVS_VOC_2_RATE, /* 1/2 rate */
MVS_VOC_1_RATE, /* full rate */
MVS_VOC_ERASURE, /* erasure frame */
MVS_VOC_8_RATE_NONCRITICAL, /* non-critical 1/8 rate */
MVS_VOC_RATE_MAX,
MVS_VOC_RATE_UNDEF = MVS_VOC_RATE_MAX
} mvs_voc_rate_type;
1.2 New APIs
mvssup_set_dtx_mode: Is the new generic API inroduced for DTX.
void mvssup_set_dtx_mode(
mvs_dtx_mode_type dtx_mode
)
Dependency:
#include "mvssup.h"
Description:
This function allows a client to turn ON or OFF the DTX mode.
Parameters:
→ mvs_dtx_mode_type : DTX mode indentifier defined as follows
typedef enum {
MVS_DTX_OFF, /* disable encoder DTX mode */
MVS_DTX_ON /* enable encoder DTX mode */
} mvs_dtx_mode_type;
MVS defines new vocoder mode as MVS_MODE_EVRC_NW
Following are the new definitions added for MVS APIs
1.1 New MVS Definitions
Following are the new values defined in the corresponding enums to support SO-73
mvs_mode_type: MVS_MODE_4GV_NW is used to denote SO-73 vocoder whereever mvs_mode_type is used. eg: mvs_enable() API should use the above enum value for SO-73.
typedef enum {
MVS_MODE_NONE,
MVS_MODE_IS733, /* QCELP-13k */
MVS_MODE_IS127, /* EVRC-8k */
MVS_MODE_4GV_NB, /* 4GV narrow band */
MVS_MODE_4GV_WB, /* 4GV wide band */
MVS_MODE_AMR, /* Adaptive multi-rate */
MVS_MODE_EFR, /* Enhanced full rate */
MVS_MODE_FR, /* Full rate */
MVS_MODE_HR, /* Half rate */
MVS_MODE_LINEAR_PCM, /* enable/disable PCM interface */
MVS_MODE_G711, /* G.711 vocoder */
MVS_MODE_G723, /* G.723 vocoder */
MVS_MODE_PCM, /* PCM vocoder */
MVS_MODE_AMR_WB, /* AMR-WB vocoder */
MVS_MODE_G729A, /* G729A vocoder */
MVS_MODE_G711A, /* G711A vocoder */
MVS_MODE_G722, /* G722 vocoder */
MVS_MODE_4GV_NW, /* 4GV narrowband-wideband */
MVS_MODE_MAX,
MVS_MODE_32BIT_DUMMY = 0x7FFFFFFF
} mvs_mode_type;
mvs_voc_rate_type: MVS_VOC_8_RATE_NONCRITICAL signifies that, the encoded packet associated with, is an Non-critical eighth rate frame.
typedef enum {
MVS_VOC_0_RATE, /* blank frame */
MVS_VOC_8_RATE, /* 1/8 rate */
MVS_VOC_4_RATE, /* 1/4 rate */
MVS_VOC_2_RATE, /* 1/2 rate */
MVS_VOC_1_RATE, /* full rate */
MVS_VOC_ERASURE, /* erasure frame */
MVS_VOC_8_RATE_NONCRITICAL, /* non-critical 1/8 rate */
MVS_VOC_RATE_MAX,
MVS_VOC_RATE_UNDEF = MVS_VOC_RATE_MAX
} mvs_voc_rate_type;
1.2 New APIs
mvssup_set_dtx_mode: Is the new generic API inroduced for DTX.
void mvssup_set_dtx_mode(
mvs_dtx_mode_type dtx_mode
)
Dependency:
#include "mvssup.h"
Description:
This function allows a client to turn ON or OFF the DTX mode.
Parameters:
→ mvs_dtx_mode_type : DTX mode indentifier defined as follows
typedef enum {
MVS_DTX_OFF, /* disable encoder DTX mode */
MVS_DTX_ON /* enable encoder DTX mode */
} mvs_dtx_mode_type;
Accessory ( Headset , Headphone , ANC Headset etc ) Detection in 8660,8260 ( 8x60) Android Builds
The Accessories that can be detected by PMIC 8058 OTHC used in 8x60 are listed in
LINUX/android/kernel/include/linux/pmic8058-othc.h
enum othc_accessory_type {
OTHC_NO_DEVICE = 0,
OTHC_HEADSET = 1 << 0,
OTHC_HEADPHONE = 1 << 1,
OTHC_MICROPHONE = 1 << 2,
OTHC_ANC_HEADSET = 1 << 3,
OTHC_ANC_HEADPHONE = 1 << 4,
OTHC_ANC_MICROPHONE = 1 << 5,
OTHC_SVIDEO_OUT = 1 << 6,
};
The Logic to decide the type of accessory is based on the detect_flags that idetifies the Accessory type and other parameters as
specified in the othc_accessories array found in the file /LINUX/android/kernel/arch/arm/mach-msm/board-msm8x60.c
The Logic to decide the type of accessory is based on the detect_flags that idetifies the Accessory type and other parameters as
specified in the othc_accessories array found in the file /LINUX/android/kernel/arch/arm/mach-msm/board-msm8x60.c
static struct othc_accessory_info othc_accessories[] = {
{
.accessory = OTHC_SVIDEO_OUT,
.detect_flags = OTHC_MICBIAS_DETECT | OTHC_SWITCH_DETECT
| OTHC_ADC_DETECT,
.key_code = SW_VIDEOOUT_INSERT,
.enabled = false,
.adc_thres = {
.min_threshold = 20,
.max_threshold = 40,
},
},
{
.accessory = OTHC_ANC_HEADPHONE,
.detect_flags = OTHC_MICBIAS_DETECT | OTHC_GPIO_DETECT |
OTHC_SWITCH_DETECT,
.gpio = PM8058_LINE_IN_DET_GPIO,
.active_low = 1,
.key_code = SW_HEADPHONE_INSERT,
.enabled = true,
},
{
.accessory = OTHC_ANC_HEADSET,
.detect_flags = OTHC_MICBIAS_DETECT | OTHC_GPIO_DETECT,
.gpio = PM8058_LINE_IN_DET_GPIO,
.active_low = 1,
.key_code = SW_HEADPHONE_INSERT,
.enabled = true,
},
{
.accessory = OTHC_HEADPHONE,
.detect_flags = OTHC_MICBIAS_DETECT | OTHC_SWITCH_DETECT,
.key_code = SW_HEADPHONE_INSERT,
.enabled = true,
},
{
.accessory = OTHC_MICROPHONE,
.detect_flags = OTHC_GPIO_DETECT,
.gpio = PM8058_LINE_IN_DET_GPIO,
.active_low = 1,
.key_code = SW_MICROPHONE_INSERT,
.enabled = true,
},
{
.accessory = OTHC_HEADSET,
.detect_flags = OTHC_MICBIAS_DETECT,
.key_code = SW_HEADPHONE_INSERT,
.enabled = true,
},
};
If OEM want to disable the detection of any accessory then they can set .enabled = false for the Accessory they dont want to support in the above table .
The decision about which Acessory is inserted or removed is done in the function
static int pm8058_accessory_report(struct pm8058_othc *dd, int status) present in the file
LINUX/android/kernel/drivers/input/misc/pmic8058-othc.c
GSBI Protocol Code/PIN mappings in MSM8660/ MSM8660A/ MSM8960
When GSBI protocol code is configured to below functions, related PIN are configured as below.
protocol code 1 I2C + SIM/R-UIM
GSBI_PO(0) i2c_clk
GSBI_PO(1) i2c_dat
GSBI_PO(2) uim_clk
GSBI_PO(3) uim_dat
Protocol code 2 I2C
GSBI_PO(0) i2c_clk
GSBI_PO(1) i2c_dat
GSBI_PO(2) not used
GSBI_PO(3) not used
Protocol code 3 SPI
GSBI_PO(0) spi_clk
GSBI_PO(1) spi_cs_n
GSBI_PO(2) spi_data_miso
GSBI_PO(3) spi_data_mosi
Protocol code 4 UART or IRDA
GSBI_PO(0) uart_rfr_n
GSBI_PO(1) uart_cts_n
GSBI_PO(2) uart_rx_dat
GSBI_PO(3) uart_tx_dat
Protocol code 5 SIM/R-UIM
GSBI_PO(0) not used
GSBI_PO(1) not used
GSBI_PO(2) uim_clk
GSBI_PO(3) uim_dat
protocol code 6 I2C + 2-wire UART
GSBI_PO(0) i2c_clk
GSBI_PO(1) i2c_dat
GSBI_PO(2) uart_rx_dat
GSBI_PO(3) uart_tx_dat
protocol code 1 I2C + SIM/R-UIM
GSBI_PO(0) i2c_clk
GSBI_PO(1) i2c_dat
GSBI_PO(2) uim_clk
GSBI_PO(3) uim_dat
Protocol code 2 I2C
GSBI_PO(0) i2c_clk
GSBI_PO(1) i2c_dat
GSBI_PO(2) not used
GSBI_PO(3) not used
Protocol code 3 SPI
GSBI_PO(0) spi_clk
GSBI_PO(1) spi_cs_n
GSBI_PO(2) spi_data_miso
GSBI_PO(3) spi_data_mosi
Protocol code 4 UART or IRDA
GSBI_PO(0) uart_rfr_n
GSBI_PO(1) uart_cts_n
GSBI_PO(2) uart_rx_dat
GSBI_PO(3) uart_tx_dat
Protocol code 5 SIM/R-UIM
GSBI_PO(0) not used
GSBI_PO(1) not used
GSBI_PO(2) uim_clk
GSBI_PO(3) uim_dat
protocol code 6 I2C + 2-wire UART
GSBI_PO(0) i2c_clk
GSBI_PO(1) i2c_dat
GSBI_PO(2) uart_rx_dat
GSBI_PO(3) uart_tx_dat
How to change mdp color space convert algorithm
Check http://en.wikipedia.org/wiki/YUV and http://en.wikipedia.org/wiki/Luma_(video)#Rec._601_luma_versus_Rec._709_luma_coefficients
The floating point 3x3 matrix in wiki page is
[1 0 1.13983 1 -0.39465 -0.58060 1 2.03211 0]
And the matrix of MDP is 3x3 so we need to multiply each coeff by (1<<9)
1*(1<<9)= 512= 0x0200
0*(1<<9)= 0= 0x0000
1.13983*(1<<9)= 584= 0x0248
-0.39465*(1<<9)= -202= -0x00CA= 0xFF36 (2's complement in 16-bit)
……
Then
static uint32 csc_matrix_tab[9]
{0x0200, 0x0000, 0x0248, 0x0200, 0xff36, 0xfed7, 0x0200, 0x0410, 0x0000};
The floating point 3x3 matrix in wiki page is
[1 0 1.13983 1 -0.39465 -0.58060 1 2.03211 0]
And the matrix of MDP is 3x3 so we need to multiply each coeff by (1<<9)
1*(1<<9)= 512= 0x0200
0*(1<<9)= 0= 0x0000
1.13983*(1<<9)= 584= 0x0248
-0.39465*(1<<9)= -202= -0x00CA= 0xFF36 (2's complement in 16-bit)
……
Then
static uint32 csc_matrix_tab[9]
{0x0200, 0x0000, 0x0248, 0x0200, 0xff36, 0xfed7, 0x0200, 0x0410, 0x0000};
How to check GPU clock for 8660/8260 in Android
In Android platform, from 8x60, we support command line clock method through ADB and debugfs.
User can check current GPU clock using ADB following below direction.
1. Mount the debug FS: adb shell "mount -t debugfs none /sys/kernel/debug"
2. Check clock speeds (for 8660):
a. 2D core #1: adb shell "cat /sys/kernel/debug/clk/gfx2d0_clk/measure"
b. 2D core #2: adb shell "cat /sys/kernel/debug/clk/gfx2d1_clk/measure" (This is only for Adreno220)
c. 3D core: adb shell "cat /sys/kernel/debug/clk/gfx3d_clk/measure"
3. Write clock speeds (for 8660):
a. 2D core #1: adb shell "echo <clock speed in Hz unit> /sys/kernel/debug/clk/gfx2d0_clk/rate"
b. 2D core #2: adb shell "echo <clock speed in Hz unit> /sys/kernel/debug/clk/gfx2d1_clk/rate" (This is only for Adreno220)
c. 3D core: adb shell "echo <clock speed in Hz unit> /sys/kernel/debug/clk/gfx3d_clk/rate"
User can check current GPU clock using ADB following below direction.
1. Mount the debug FS: adb shell "mount -t debugfs none /sys/kernel/debug"
2. Check clock speeds (for 8660):
a. 2D core #1: adb shell "cat /sys/kernel/debug/clk/gfx2d0_clk/measure"
b. 2D core #2: adb shell "cat /sys/kernel/debug/clk/gfx2d1_clk/measure" (This is only for Adreno220)
c. 3D core: adb shell "cat /sys/kernel/debug/clk/gfx3d_clk/measure"
3. Write clock speeds (for 8660):
a. 2D core #1: adb shell "echo <clock speed in Hz unit> /sys/kernel/debug/clk/gfx2d0_clk/rate"
b. 2D core #2: adb shell "echo <clock speed in Hz unit> /sys/kernel/debug/clk/gfx2d1_clk/rate" (This is only for Adreno220)
c. 3D core: adb shell "echo <clock speed in Hz unit> /sys/kernel/debug/clk/gfx3d_clk/rate"
How to override Processor Voltage Setting (PVS) in MSM8660/APQ8060 Linux/Anrdroid device
On MSM8660/8260 and APQ8060 devices that support 1.5 GHz Scorpion speed, PVS support is implemented.
This feature enables using different table for Scorpion Voltage levels (VDDSCx) depending on efuse bit setting.
The tables for PVS are defined in acpuclock-8x60.c in arch/arm/mach-msm/ directory for kernel code.
Three levels are supported. They are HIGH, MEDIUM, and LOW.
For testing or debugging some issues, there may be a need to disable PVS.
When this is done it defaults to the LOW setting.
Override can be accomplished by modifying one line of code in the function select_freq_plan(void) in the file acpuclock-8x60.c.
The needed modification sets pvs value to zero when acpu_freq_table is picked based on detected pvs value.
Insert a line
pvs = 0;
right before
This feature enables using different table for Scorpion Voltage levels (VDDSCx) depending on efuse bit setting.
The tables for PVS are defined in acpuclock-8x60.c in arch/arm/mach-msm/ directory for kernel code.
Three levels are supported. They are HIGH, MEDIUM, and LOW.
For testing or debugging some issues, there may be a need to disable PVS.
When this is done it defaults to the LOW setting.
Override can be accomplished by modifying one line of code in the function select_freq_plan(void) in the file acpuclock-8x60.c.
The needed modification sets pvs value to zero when acpu_freq_table is picked based on detected pvs value.
Insert a line
pvs = 0;
right before
switch (pvs)
in the function mentioned above.5/15/2012
How to Write IMEI Without QPST or QXDM
MEI is an NV Item (550) and is a 9*8 bit structure. Use CMD_CODE 39 (Nonvolatile Item Write) Request Message to build the command for this NV item with ITEM_DATA as follows...
IMEI - 15 digits. 15th (spare) digit normally '0'.
IMEI example "123456-78-9012340"
{ 0x08, 0x1A, 0x32, 0x54, 0x76, 0x98, 0x10, 0x32, 0x04 }
| || |
/ || |
length || |
/ | /
1st digit | 15th digit
/
always A
"length" always set to 8.
5/13/2012
eMMC Partition tools usage for msm7x30/msm8x60
In the emmc boot, There are some changes in emmc partition
partition.xml � Everything begins with this file, which describes the number of partitions desired, and how many
sectors each one should be.
PartitioningTool.py � translates partition.xml into binary partitions
msp.exe � writes binary partitions to SD/eMMC cards using card reader
mjsdload.cmm � writes binary partitions to SD/eMMC cards using Trace32
msp.py � writes binary partitions to a single image file
QPST � writes binary partitions to SD/eMMC cards on Target
Helper /Debug Tools
parseBinaryPartitionFile.pl � decodes MBR partition tables . Run "Perl parseBinaryPartitionFile.pl partition.bin"
can generate the partition information
parseGPT.pl � decodes GPT partition tables
Partition.xml
There add some property entry can be added in new partiton.xml to specified the configuration.
<parser_instructions>
WRITE_PROTECT_BOUNDARY_IN_KB = 0
GROW_LAST_PARTITION_TO_FILL_DISK = false
ALIGN_ALL_LOGICAL_PARTITIONS_TO_WP_BOUNDARY = false
</parser_instructions>
WRITE_PROTECT_BOUNDARY_IN_KB: Typical boundaries are 64MB, i.e. 65536 KB. This means that a 256MB eMMC
card has 4 write protect boundaries. Any or all of them can be marked as read-only. Different vendors allow
for different sized boundaries.
GROW_LAST_PARTITION_TO_FILL_DISK: In partition.xml the size of each partition is specified. If this field
is TRUE, then the last partition size is ignored and set to 0. Then during patching this size is updated
such that the last partition extends to use all remaining space.
ALIGN_ALL_LOGICAL_PARTITIONS_TO_WP_BOUNDARY: To allow total flexibility, it could be that a partition that
is currently writeable might need to be marked as read-only. This can only happen *if* that partition begins
on a write protect boundary (i.e. 64MB). Thus if this field is TRUE, then all logical partitions are
positioned such that they begin on a write protect boundary.
More detail, please refer 80-N4584-1 eMMC_Partition_Tables_Raw_Program for the detail.
PartitioningTool.py , new tools used to generate the the partition.xml
When run the PartitioningTool.py, it will output following files
1. emmc_lock_regions.xml � holds the sector ranges that need to be marked as read-only by the operating system (this is
from readonly="true" in partition.xml)
i.e. modem code and boot images are typically on read-only partitions
Typical Write-Protect boundary is 64MB = 131072 sectors = 0x20000 sectors This file below is protecting the very first
64MB region of the card, Boundary #0
Starting at sector 0
Ending at sector 131071 (for a total of 131072 sectors)
<?xml version="1.0" ?>
<protect>
<!-- NOTE: This is an ** Autogenerated file ** -->
<!-- NOTE: Sector size is 512bytes, WRITE_PROTECT_BOUNDARY_IN_KB=0, WRITE_PROTECT_BOUNDARY_IN_SECTORS=0 -->
<!-- NOTE: "num_sectors" in HEX "start_sector" in HEX, i.e. 10 really equals 16 !! -->
<program boundary_num="0" num_boundaries_covered="1"
num_sectors="20000" num_sectors_dec="131072" physical_partition_number="0"
start_sector="0" start_sector_dec="0"/>
<information WRITE_PROTECT_BOUNDARY_IN_KB="0"/>
</protect>
2.partition0.bin � holds the partition tables, i.e. MBR followed by all EBRs
This is the partition table in binary format. It is copied over to the storage device in a 1 to 1 manner.
i.e. how it looks in partition0.bin is exactly how the partition table will look on the storage device.
partition0.bin s a "generic" file meant to fit on *any* size SD/eMMC card, as a result, there are 0's that need to be
patched,such as EXT partition and last partition size.
3. patch0.xml � patching instructions to tailor each partition table "partition0.bin" to a specific SD/eMMC card
i.e. the partition0.bin partition tables can be applied to any size storage device
As a result, there are empty values (zeros) in the partition tables that must be filled in with a specific cards sector size
There are two ways to apply this patch
(patch before) When you patch the "zeros" in the partition tables held in the file partition0.bin, and then write it to the card
(patch after) When you write partition0.bin to the card (which still has "zeros" in it), and then patch the cards partition
tables directly
4.rawprogram0.xml � precise sector details of all partitions and what files (if any) need to be placed there,In addition to
writing partition tables onto a device, often times it is desired to write one or more files into the partition area as well,
The File has partition name (i.e. label), where it begins (start_sector) and how big it is (num_partition_sectors) It also
describes what file(s) to write to this partition, as well as any offsets.
example
<program file_sector_offset="0" filename="partition0.bin" label="MBR"
num_partition_sectors="1" physical_partition_number="0"
size_in_KB="0.5" start_sector="0"/>
<program file_sector_offset="1" filename="partition0.bin " label="EXT"
num_partition_sectors="2" physical_partition_number="0"
size_in_KB="1.0" start_sector="779"/>
The 1st line describes taking the 1st sector from partition0.bin, and writing it to
sector 0 of the card
The 2nd line describes taking the 2nd and 3rd sector from partition0.bin and writing it to sector
779 of the card
i.e. file_sector_offset = 2 and num_partition_sectors=2
5.loadpt.cmm: used by the mjsdload.cmm to flash the image.
msp.exe .used to apply the patches
This program will program a memory card (SD/eMMC) attached to the PC as USB mass storage device
Use -d to detect the path of the memory card if you are unsure what to do first
Commands list:
-h (Print this help message) Ex. msp -h
-d (Detect which storage device ID is active) Ex. msp -d
-p (Print partition information) Ex. msp -p /dev/sdb
-pp (Print partition information - DETAILED) Ex. msp -pp /dev/sdb
-x (Write files as outlined in rawprogram.xml) Ex. msp -x rawprogram.xml /dev/sdb
-xx (Write files as outlined in rawprogram.xml - DETAILED) Ex. msp -xx rawprogram.xml /dev/sdb
-s (Write SINGLE IMAGE "singleimage.bin" as outlined in rawprogram.xml) Ex. msp -s rawprogram.xml 8192
-v (Verify file written correctly as outlined in rawprogram.xml) Ex. msp -v rawprogram.xml boot.img /dev/sdb
-f (Program single file as outlined in rawprogram.xml) Ex. msp -f rawprogram.xml boot.img /dev/sdb
Program the SD/eMMC with msp.exe in mass storage mode
STEPS Complete example (patchafter)
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Program your device msp �x rawprogram0.xml /dev/sdb
Patch your device msp �xx patch0.xml /dev/sdb
STEPS Complete example (patchbefore)
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Patch your files msp �xx patch0.xml 15758336 (patch the 8GB card offline,this will change the partition0.bin)
Program your device msp �x rawprogram0.xml /dev/sdb
the msp.py can also used to patch the files , such as
python msp.py patch0.xml 15758336 ( (patch the 8GB card offline,this will change the partition0.bin)
partition.xml � Everything begins with this file, which describes the number of partitions desired, and how many
sectors each one should be.
PartitioningTool.py � translates partition.xml into binary partitions
msp.exe � writes binary partitions to SD/eMMC cards using card reader
mjsdload.cmm � writes binary partitions to SD/eMMC cards using Trace32
msp.py � writes binary partitions to a single image file
QPST � writes binary partitions to SD/eMMC cards on Target
Helper /Debug Tools
parseBinaryPartitionFile.pl � decodes MBR partition tables . Run "Perl parseBinaryPartitionFile.pl partition.bin"
can generate the partition information
parseGPT.pl � decodes GPT partition tables
Partition.xml
There add some property entry can be added in new partiton.xml to specified the configuration.
<parser_instructions>
WRITE_PROTECT_BOUNDARY_IN_KB = 0
GROW_LAST_PARTITION_TO_FILL_DISK = false
ALIGN_ALL_LOGICAL_PARTITIONS_TO_WP_BOUNDARY = false
</parser_instructions>
WRITE_PROTECT_BOUNDARY_IN_KB: Typical boundaries are 64MB, i.e. 65536 KB. This means that a 256MB eMMC
card has 4 write protect boundaries. Any or all of them can be marked as read-only. Different vendors allow
for different sized boundaries.
GROW_LAST_PARTITION_TO_FILL_DISK: In partition.xml the size of each partition is specified. If this field
is TRUE, then the last partition size is ignored and set to 0. Then during patching this size is updated
such that the last partition extends to use all remaining space.
ALIGN_ALL_LOGICAL_PARTITIONS_TO_WP_BOUNDARY: To allow total flexibility, it could be that a partition that
is currently writeable might need to be marked as read-only. This can only happen *if* that partition begins
on a write protect boundary (i.e. 64MB). Thus if this field is TRUE, then all logical partitions are
positioned such that they begin on a write protect boundary.
More detail, please refer 80-N4584-1 eMMC_Partition_Tables_Raw_Program for the detail.
PartitioningTool.py , new tools used to generate the the partition.xml
When run the PartitioningTool.py, it will output following files
1. emmc_lock_regions.xml � holds the sector ranges that need to be marked as read-only by the operating system (this is
from readonly="true" in partition.xml)
i.e. modem code and boot images are typically on read-only partitions
Typical Write-Protect boundary is 64MB = 131072 sectors = 0x20000 sectors This file below is protecting the very first
64MB region of the card, Boundary #0
Starting at sector 0
Ending at sector 131071 (for a total of 131072 sectors)
<?xml version="1.0" ?>
<protect>
<!-- NOTE: This is an ** Autogenerated file ** -->
<!-- NOTE: Sector size is 512bytes, WRITE_PROTECT_BOUNDARY_IN_KB=0, WRITE_PROTECT_BOUNDARY_IN_SECTORS=0 -->
<!-- NOTE: "num_sectors" in HEX "start_sector" in HEX, i.e. 10 really equals 16 !! -->
<program boundary_num="0" num_boundaries_covered="1"
num_sectors="20000" num_sectors_dec="131072" physical_partition_number="0"
start_sector="0" start_sector_dec="0"/>
<information WRITE_PROTECT_BOUNDARY_IN_KB="0"/>
</protect>
2.partition0.bin � holds the partition tables, i.e. MBR followed by all EBRs
This is the partition table in binary format. It is copied over to the storage device in a 1 to 1 manner.
i.e. how it looks in partition0.bin is exactly how the partition table will look on the storage device.
partition0.bin s a "generic" file meant to fit on *any* size SD/eMMC card, as a result, there are 0's that need to be
patched,such as EXT partition and last partition size.
3. patch0.xml � patching instructions to tailor each partition table "partition0.bin" to a specific SD/eMMC card
i.e. the partition0.bin partition tables can be applied to any size storage device
As a result, there are empty values (zeros) in the partition tables that must be filled in with a specific cards sector size
There are two ways to apply this patch
(patch before) When you patch the "zeros" in the partition tables held in the file partition0.bin, and then write it to the card
(patch after) When you write partition0.bin to the card (which still has "zeros" in it), and then patch the cards partition
tables directly
4.rawprogram0.xml � precise sector details of all partitions and what files (if any) need to be placed there,In addition to
writing partition tables onto a device, often times it is desired to write one or more files into the partition area as well,
The File has partition name (i.e. label), where it begins (start_sector) and how big it is (num_partition_sectors) It also
describes what file(s) to write to this partition, as well as any offsets.
example
<program file_sector_offset="0" filename="partition0.bin" label="MBR"
num_partition_sectors="1" physical_partition_number="0"
size_in_KB="0.5" start_sector="0"/>
<program file_sector_offset="1" filename="partition0.bin " label="EXT"
num_partition_sectors="2" physical_partition_number="0"
size_in_KB="1.0" start_sector="779"/>
The 1st line describes taking the 1st sector from partition0.bin, and writing it to
sector 0 of the card
The 2nd line describes taking the 2nd and 3rd sector from partition0.bin and writing it to sector
779 of the card
i.e. file_sector_offset = 2 and num_partition_sectors=2
5.loadpt.cmm: used by the mjsdload.cmm to flash the image.
msp.exe .used to apply the patches
This program will program a memory card (SD/eMMC) attached to the PC as USB mass storage device
Use -d to detect the path of the memory card if you are unsure what to do first
Commands list:
-h (Print this help message) Ex. msp -h
-d (Detect which storage device ID is active) Ex. msp -d
-p (Print partition information) Ex. msp -p /dev/sdb
-pp (Print partition information - DETAILED) Ex. msp -pp /dev/sdb
-x (Write files as outlined in rawprogram.xml) Ex. msp -x rawprogram.xml /dev/sdb
-xx (Write files as outlined in rawprogram.xml - DETAILED) Ex. msp -xx rawprogram.xml /dev/sdb
-s (Write SINGLE IMAGE "singleimage.bin" as outlined in rawprogram.xml) Ex. msp -s rawprogram.xml 8192
-v (Verify file written correctly as outlined in rawprogram.xml) Ex. msp -v rawprogram.xml boot.img /dev/sdb
-f (Program single file as outlined in rawprogram.xml) Ex. msp -f rawprogram.xml boot.img /dev/sdb
Program the SD/eMMC with msp.exe in mass storage mode
STEPS Complete example (patchafter)
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Program your device msp �x rawprogram0.xml /dev/sdb
Patch your device msp �xx patch0.xml /dev/sdb
STEPS Complete example (patchbefore)
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Patch your files msp �xx patch0.xml 15758336 (patch the 8GB card offline,this will change the partition0.bin)
Program your device msp �x rawprogram0.xml /dev/sdb
the msp.py can also used to patch the files , such as
python msp.py patch0.xml 15758336 ( (patch the 8GB card offline,this will change the partition0.bin)
5/11/2012
SDRAM wait states customization for Hynix DDR SDRAM on various MSM7K devices
clkrgm_msm.c or clkrgm_mpss_sdram_7627.c
void clk_regime_sdram_init (void)
{
<snip>
if (tRAS > 7)
{
tRAS = 7;
}
/*------------------------------------------------------------------------------------------------------*/
/* Hynix Special Requirement for tDAL, tWR, and tRP */
/* Minimum 3CLK of tDAL(= tWR+tRP) is required because it need minimum 2CLK for tWR and minimum 1CLK for tRP */
/* Refer to Hynix datasheet */
if (tWR < 1)
{
tWR = 1;
}
tDAL = tWR + tRP +1 ;
/*------------------------------------------------------------------------------------------------------*/
clkrgm_mpss_sdram_cfg[i].ebi_sdram_mem_device_parameter_cfg1 =
HWIO_FVAL(EBI_SDRAM_MEM_DEVICE_PARAMETER_CFG1, TRFC,
(tRFC>=16? tRFC-16 : tRFC)) |
HWIO_FVAL(EBI_SDRAM_MEM_DEVICE_PARAMETER_CFG1, TRP, tRP) |
HWIO_FVAL(EBI_SDRAM_MEM_DEVICE_PARAMETER_CFG1, TRAS, tRAS) |
HWIO_FVAL(EBI_SDRAM_MEM_DEVICE_PARAMETER_CFG1, TRC, tRC) |
HWIO_FVAL(EBI_SDRAM_MEM_DEVICE_PARAMETER_CFG1, TMRD, tMRD);
<snip>
Without this various symptoms such as reset or lock-up might be observed when Hynix (or Elpida) DDR device applied at clock switching scenario.
How to adding new clock frequency setting for MDDI and LCDC
To get the available MDDI and LCDC clock setting, you can solution# 00014854 for 8650, 7227 and 7225.
For 7630, you can check clock setting list in clkrgm_bsp_7630.c located at AMSS\products\7x30\core\systemdrivers\clkregim\src\common
By the way, sometime, there is not pre-defined clock setting you want to use. In that case, you can add your own clock frequency setting table as below.
There are two kinds of tables as below. One is table for clock which derived from simple division, the other is for clock which needs more complex calculation.
Based on your target frequency, you can select clock source and Multiplier and Divider and add new table.
Each calculation is like this.
* Complex table: target_freq (.freq_hz) = (source_freq (.hal_cfg.eSource) * Multiplier (.hal_cfg.nM)) / (DividerA (.hal_cfg.nDivider) * DividerB (.hal_cfg.nN)
[CLKRGM_PIXEL_SPEED_70_MHZ] =
{
.freq_hz = 73728 * 1000,
.hal_cfg.eSource = HAL_CLK_SOURCE_PLL3, /// 737.28 * 1000000
.hal_cfg.nDivider = 2,
.hal_cfg.nM = 1,
.hal_cfg.nN = 5,
.hal_cfg.n2D = 5 /// Use same value with .hal_cfg.nN
},
ex) 73728*1000 = (737.28 * 1000000 * 1) / (2 * 5)
* Simple table: target_freq (.freq_hz) = source_freq (.hal_cfg.eSource) / Divider (.hal_cfg.nDivider)
[CLKRGM_PIXEL_SPEED_25_MHZ] =
{
.freq_hz = 24576 * 1000,
.hal_cfg.eSource = HAL_CLK_SOURCE_LPXO, /// 24576 * 1000
.hal_cfg.nDivider = 1
},
ex) 24576 * 1000 = 24576 * 1000 / 1
5/10/2012
How to debug the LK bootloader used in Android Builds
LK is a new bootloader for Android, and the LK bootloader was introduced in QCT Eclair release.
Below is the step for debugging the LK bootloader with source level.
- In file /LINUX/android/bootable/bootloader/lk/arch/arm/crt0.S, make a modification as below:
_start:
b _start /*Add this line to make bootloader loop here forever*/
b reset - Use ARM11 or Scorpion JTAG, attach to target
- Download debug symbol to target by using following command
d.load.elf V:/LINUX/android/out/target/product/qsd8250_surf/obj/BOOTLOADER_OBJ/build-qsd8250_surf/lk /nocode - After setting desired breakpoint which you are interesting, set the Program Counter (PC) after the b start
(i.e., b reset) to start debugging LK bootloader. - Please upgrade the T32 software's date up to Dec.04.2009 or later to enable source level debugging.
Contiguous display from app boot loader to kernel/android in msm7x27
Nowadays, lot of customers require contiguous display from app bootloader to kernel/android without black screen or diming panel. It is simple to say that they want bootloader splash image to be seen until Android splash image boots up.
As we know, the initial state of mdp/pixel clock are off by default when linux kernel startup, but as for splash image display during OEMSBL or AP bootloader, the mdp clock, pixel clock, and lcdc are already on, which conflict with the linux kernel's assumption. In linux kernel, there are some control logic and reference count to manage the mdp/pixel clock, the core logic is within function: void mdp_pipe_ctrl(subblock, powerstate, inisr). In the startup process, most of time mdp_pipe_ctrl(poweron) and mdp_pipe_ctrl(poweroff) are using in pair in one function to keep the reference count matched, so it will always try to keep clock in off state to save power consume.
Because linux kernel does not know the initial state of our mdp/pixel clock are on, so if we don't make any changes, the mdp/pixel clock will be disabled at the beginning of of kernel startup, and re-enabled until linux kernel enable display. so we must bypass the mdp/pixel clock control logic until kernel first time enable display.
As there is a time out value (mdp_timer_duration = 1HZ) used to control the disable of mdp/pixel clock, so we can enlarge this value ( 100HZ) to
skip the real operation of mdp/pixel clock off for this backdoor purpose.
The detailed changes are in the file attached.
/*==================================================================*/
1. Changes in mdp.c
/* Add a global flag to indicate supporting of the feature:
continuous display from app bootloader to kernel/android
*/
+ boolean mdp_continues_display = TRUE;
2. Changes in mdp_dma_lcdc.c
+ extern unsigned long mdp_timer_duration;
/* Defined in mdp.c to indicate support appboot logo display*/
+ extern boolean mdp_continues_display;
int mdp_lcdc_on(struct platform_device *pdev)
{
<~put in the end of this function~>
<~snip~>
+ if(mdp_continues_display) {
+ mdp_continues_display = FALSE;
+ mdp_timer_duration = (HZ);
+ }
<~snip~>
}
3. Changes in mdp_hw_init.c
+ extern unsigned long mdp_timer_duration;
+ extern boolean mdp_continues_display;
void mdp_hw_init(void)
{
<~snip~>
mdp_timer_duration = (100 * HZ); /* 100 sec */
<~snip~>
#ifndef CONFIG_FB_MSM_MDP22
+ /* skip the code to avoid LCDC is to be disable */
+ if (!mdp_continues_display) {
MDP_OUTP(MDP_BASE + 0xE0000, 0);
MDP_OUTP(MDP_BASE + 0x100, 0xffffffff);
MDP_OUTP(MDP_BASE + 0x90070, 0);
MDP_OUTP(MDP_BASE + 0x94010, 1);
MDP_OUTP(MDP_BASE + 0x9401c, 2);
+ }
8960 Android GSBI UART Debug Tips
1. Check Registration
Run following commands to test if UART is properly registered with TTY stack.
adb shell -> Starts a new shell
ls /dev/ttyHS* -> lists all the current serial ports registered with TTY layer.
Low speed UART would be listed as ttyHSL#
High speed UART would be listed as ttyHS#
2. Check Internal Loop-back
Run following commands to test UART block with internal loop back enabled.
adb shell
mount -t debugfs none /sys/kernel/debug -> mount debug file system
cd /sys/kernel/debug/msm_serial_hs -> for high speed UART
cd /sys/kernel/debug/msm_serial_hsl -> for low speed UART
echo 1 > loopback.# -> Enable loop back.
cat loopback.# -> To verify loop back is enabled.
Open another cmd window and type following command to print UART RX Data
adb shell
cat /dev/ttyHS# -> if you're testing High speed UART
cat /dev/ttyHSL# -> if you're testing Low speed UART
Go back to first shell and type following cmd to transmit test data
echo "Testing Low Speed UART" > /dev/ttyHS# -> If you're testing high speed UART
echo "Testing High Speed UART" > /dev/ttyHSL# -> If you're testing low speed UART
If the echo completes immediately and loop back works then you can safely assume UART block and DMA configuration are set up properly (Only need to verify GPIO related configurations).
Following section describe some of key registers that needs to be verified in case UART is not working properly. After attaching debugger to Krait core, user can use command D AZ:PhysicalAddress to get the register readings. Also all the physical addresses listed below are for information only. Please refer to software interface manual for latest physical address and bit settings information.
3. ADM related registers
Following registers used to select between QUP or UART
0x1A400070 = TCSR_ADM_0_A_CRCI_MUX_SEL
0x1A400074 = TCSR_ADM_0_A_CRCI_MUX_SEL
Following register select primarily or secondary device (CRCIn_MUX_SEL) and
correct block size (CRCIn_BLOCK_SIZE).
0x18300400 + 4 * (n) = ADM3_0_HI_CRCIn_CTL_SD0 where n is the CRCI number
For example:
0x18300404 = ADM3_0_HI_CRCI1_CTL_SD0
0x18300408 = ADM3_0_HI_CRCI2_CTL_SD0
Make sure to set following bits on following clock register before accessing
above registers:
0x00903080 = SC0_U_CLK_BRANCH_ENA_VOTE [Set Bit #2 and Bit #3]
4. GSBI CTRL Registers
Make sure GSBIn_HCLK_CTL[4] is set before accessing below GSBI registers
0x009029C0 + ( 32 * (n - 1 ) ) = GSBIn_HCLK_CTL
For example:
0x009029C0 = GSBI1_HCLK_CTL
0x009029E0 = GSBI2_HCLK_CTL
Check to make sure GSBI CTRL REG[PROTOCOL CODE] is set properly.
0x16000000 = GSBI1_CTRL_REG
0x16100000 = GSBI2_CTRL_REG
0x16200000 = GSBI3_CTRL_REG
0x16300000 = GSBI4_CTRL_REG
0x16400000 = GSBI5_CTRL_REG
0x16500000 = GSBI6_CTRL_REG
0x16600000 = GSBI7_CTRL_REG
0x1A000000 = GSBI8_CTRL_REG
0x1A100000 = GSBI9_CTRL_REG
0x1A200000 = GSBI10_CTRL_REG
0x12440000 = GSBI11_CTRL_REG
0x12480000 = GSBI12_CTRL_REG
5. GPIO_CFGn Registers
Check to make sure FUNC_SEL is set to GSBI, and GPIO_PULL is set to No Pull ("00")
0x00801000 + 0x10(n) = GPIO_CFGn
For Example:
0x00801000 = GPIO_CFG0
0x00801010 = GPIO_CFG1
Subscribe to:
Posts (Atom)