Snapdragon 410 fails to boot at pm_driver_init

Products Support DragonBoard410c
#1

I am running the Debian build on a Snapdragon 410 SOM with a custom board.

On the PM8916 datasheet (Pg. 25), it lists the operating conditions for VBAT,VBAT_SNS to be 3.0V(Min), 3.6V(Typ), and 4.5V(Max).
My custom board supplies 3.3V to VBAT,VBAT_SNS on the PMIC.
*Note: This differs from the the typical 3.6V or 3.7V on the dragonboard 410c.

I’ve tested various supply voltages to VBAT,VBAT_SNS on my board.
My board is able to boot completely when I supply above 3.4V.
However, when my voltage is below 3.4V, I get stuck at “pm_driver_init, Start”.
Here is the boot log from serial console when my voltage is below 3.4V:

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.BF.3.0-00261
S - IMAGE_VARIANT_STRING=HAAAANAAA
S - OEM_IMAGE_VERSION_STRING=C-BPATTH
S - Boot Config, 0x000002e1
S - Core 0 Frequency, 0 MHz
B - 1544 - PBL, Start
B - 3488 - bootable_media_detect_entry, Start
B - 45648 - bootable_media_detect_success, Start
B - 45652 - elf_loader_entry, Start
B - 46868 - auth_hash_seg_entry, Start
B - 47078 - auth_hash_seg_exit, Start
B - 61204 - elf_segs_hash_verify_entry, Start
B - 120081 - PBL, End
B - 127551 - SBL1, Start
B - 190899 - pm_device_init, Start
D - 14731 - pm_device_init, Delta
B - 206241 - boot_flash_init, Start
D - 0 - boot_flash_init, Delta
B - 210267 - boot_config_data_table_init, Start
D - 21777 - boot_config_data_table_init, Delta - (0 Bytes)
B - 236588 - CDT version:3,Platform ID:24,Major ID:1,Minor ID:0,Subtype:0
B - 242810 - sbl1_ddr_set_params, Start
B - 246501 - cpr_init, Start
D - 0 - cpr_init, Delta
B - 252113 - Pre_DDR_clock_init, Start
D - 183 - Pre_DDR_clock_init, Delta
D - 0 - sbl1_ddr_set_params, Delta
B - 264618 - pm_driver_init, Start

It appears there is a check at boot (inside SBL code) that prevents the board from booting when VBAT,VBAT_SNS is below 3.4V.

Unfortunately, the current design for my board does have a way to supply 3.4V to VBAT,VBAT_SNS.
Is there any way that I can either request access to the SBL code or request a build be made that allows me to boot below 3.4V?

Thanks!

#2

Hi @wcampbell,

We are happy to hear that you are conducting deep engineering on the DragonBoard 410c.

Unfortunately, we do not have the source and not able to rebuild the Secondary Boot Loader (SBL) to customize to make it boot bellow 3.4V.

I only could suggest to use your board with 3.4V for VBAT,VBAT_SNS at the moment.

#3

Please forgive my asking but why are you using the SBL for Arrow’s Dragonboard 410c on your SOM? The most important function of the SBL is to do a bunch of board specific setup (and self checks) before jumping to the Little Kernel bootloader (which has far fewer per-board changes).

Normally the SBL (and support for it) comes from the board/SOM manufacturer; they are much more likely to be able to help you get a custom SBL for your use case (assuming they don’t already provide one).

#4

Hi danielt,

Unfortunately, the SOM manufacturer only has support for Android at this time. However, I would prefer to run embedded Linux for a number of reasons. In testing my board with input voltage above 3.4V, I have not had any problems using the provided Arrow Dragonboard 410c SBL. As Akira has suggested, I will likely have to modify the board to supply 3.4V at this time.

Thank you all for the advice.

#5

Hi @wcampbell,

I believe the 3.4V limit is common among all Qualcomm boards I’ve seen so far. The normal procedure is to start trickle charge of the battery and wait for the battery to reach this level, which should be enough for voltage drops during boot not to trigger the under voltage protection (or brown-out).

There are a few modifications done in the DB410c LK, but you should be able to boot your Linux system from the SOM SBL/LK without difficulties. You will need to boot the MDSP for WiFi to work and there are some discussed changes in future versions that will cause issues. But for now I would recommend running with the vendor supplied boot steps.

Regards,
Bjorn

#6

Hi wcampbell,

Did you solve your problem about the boot at pm_driver_init, Start?

I am having the same problem at the moment!

When I initialise the program it fails at pm_driver_init, Start.

I’m using the Eragon 410: EIC-Q410-200 - Qualcomm Snapdragon410 module.

#7

Hi JJCHAN,

I am not familiar with the Eragon 410: EIC-Q410-200 module. However, we have worked around this issue. Although, if you use this solution, I advise you do so with caution.

Our workaround is based under the assumption that only the VBAT_SNS pin is used as the battery sense point. This is noted on Table 2-2 of the PM8916 datasheet. We developed some circuitry for deriving the 3.8V from our input voltage and supply that to the VBAT_SNS pin. By doing this, we effectively trick the PMIC that we have a 3.8V battery. In reality, we actually supply 3.3V to VBAT from our switching regulator and a 3.8V derived from our input voltage to VBAT_SNS. This essentially allows us to operate the 410 at 3.3V. So far (Over a year now) we haven’t had any issues operating like this.

Also, If we had the SBL source, we could probably change the values that are expected from VBAT_SNS and not have to create this workaround. If you can manage to convince Eragon or Qualcomm (good luck), who both likely have the ability to do so, then that may be a better solution.

1 Like
#8

Hi, thanks your reply!
We have also found a solution to our issue! After testing the circuit there was one supply point - pin13(PRE_BUCK_OUT) that was not connected!! Thankyou for the advice & guidance:+1:

[If you can manage to convince Eragon or Qualcomm (good luck), who both likely have the ability to do so, then that may be a better solution.] - Still no reply from either for technical data/docs, it must be highly classified information!

#9

Couldn’t say… I’m not allowed to see the SBL sources :wink: but, for sure, it the SoM vendor that is responsible to supply and support the SBL for their SoM. However if eInfoChips don’t support non-Android systems then I guess @JJCHAN’s trick does have a lot of “hack value”.

1 Like