Linux/DRA722: J6E boot up stucking in SPL

Andy Huang18

Part Number: DRA722

Tool/software: Linux

Hi,

We have custom daughter board + custom DRA722 CPU module board with uboot 2014.07 in glsdk 7.03.00.00.3 , but some our CPU modules which filter out by our MP line are bad.

Because those CPU modules can not boot up successfully , the boot log only print 2 lines.

U-Boot SPL 2014.07 (Dec 08 2016 - 15:53:31)
DRA722-GP ES1.0

So I add some debug message in SPL code , I found the SPL stuck in reading PMCTRL_ISOCLK_STATUS like below , ISOCLK_STATUS is always zero and stuck in while loop .

arch/arm/cpu/armv7/omap5/dra7xx_iodelay.c
if (!wait_on_value(PMCTRL_ISOCLK_STATUS_MASK, PMCTRL_ISOCLK_STATUS_MASK,
(u32 *)(*prcm)->prm_io_pmctrl, LDELAY))

Could you give us some direction to debug it ? ( it should be h/w issue , but we want to know which part is NG )

Best,

Andy

over 8 years ago

0 Stanislav Stilyanov over 8 years ago

TI__Mastermind 18030 points

Hi Andy,

Can you post the schematic part of all pins related to RTC module?

Regards,

Stan

0 Pavel Botev over 8 years ago

TI__Guru**** 170625 points

Andy,

See if the below wiki pages will be in help:

processors.wiki.ti.com/.../Debug_Tips_for_DM81xx_Boot_Fail
processors.wiki.ti.com/.../AM335x_board_bringup_tips

processors.wiki.ti.com/.../AM57xx_Schematic_Checklist
processors.wiki.ti.com/.../AM57x_Hardware_Design_Guide
processors.wiki.ti.com/.../Hardware_Design_Checklist
processors.wiki.ti.com/.../Sitara_Layout_Checklist

0 Stanislav Stilyanov over 8 years ago

TI__Mastermind 18030 points

Hi Andy,
Did you manage to solve your issue?

0 Andy Huang18 over 8 years ago in reply to Stanislav Stilyanov

Expert 1005 points

Hi Stan,

The issue is still pending . We attach the relative circuit for your reference.

We already measured the RTC_OSC_XI_CLKIN32 is high level and RTC_ISO is ok on the bad J6E CPU module.

Which part should we check in advance ?

Best,

Andy

0 Stanislav Stilyanov over 8 years ago in reply to Andy Huang18

TI__Mastermind 18030 points

Andy,

Please re-attach the image. Pasting to window doesn't work in this forum.

0 Andy Huang18 over 8 years ago in reply to Stanislav Stilyanov

Expert 1005 points

Hi Stan,

Is it enough for your debug ?

0 Stanislav Stilyanov over 8 years ago in reply to Andy Huang18

TI__Mastermind 18030 points

Hi Andy,
I was mistakenly thinking this is related to other issue involving RTC_ISO not being connected properly. In your case RTC_ISO is fine.
However, please see if you have implemented the following workaround in SPL:

i890 MMC1 IOs and PBIAS Must Be Powered-Up before Isolation
CRITICALITY: Medium
DESCRIPTION: IO Isolation, as described in TRM section “Isolation Requirements”, may fail if the MMC1
IOs and PBIAS are not powered-up.
WORKAROUND: Power-up the MMC1 IOs and PBIAS before starting the Isolation Sequence. This can be
done by setting the CTRL_CORE_CONTROL_PBIAS[27] SDCARD_BIAS_PWRDNZ
and CTRL_CORE_CONTROL_PBIAS[26] SDCARD_IO_PWRDNZ bits to 1.
REVISIONS IMPACTED: SR 1.0, 1.1, 2.0

This is also described in TRM section Isolation Requirements.

Regards,
Stan

0 Ren Bowei over 8 years ago in reply to Stanislav Stilyanov

Intellectual 650 points

Dear Stan,

I have checked the source code and found out these two bits are 1 originally.
In the file "arm/include/asm/arch-omap5/omap.h",
#define SDCARD_BIAS_PWRDNZ (1 << 27)
#define SDCARD_PWRDNZ (1 << 26)

It should be the HW issue, but we still need to know which part is NG.
I'm looking forward to your reply, thank you.

Best Regards,
Bowei Ren

0 Ren Bowei over 8 years ago in reply to Ren Bowei

Intellectual 650 points

Hi Stan,

update.
Sorry, I have something wrong. This file (omap.h) cannot check the register value is correct or not.
So I used CCS tool to check register value which you suggest.
SDCARD_BIAS_PWRDNZ and SDCARD_IO_PWRDNZ bits are set to 1 already.

Best Regards,
Bowei Ren

0 Stanislav Stilyanov over 8 years ago in reply to Ren Bowei

TI__Mastermind 18030 points

Hi Ren,
Ok, thanks. You are reading them during the 'wait' hang, correct?

The ISOCLKOUT signal travels from one I/O pad to the next until it reaches the register bit. See Figure 3-97. I/O Pads Daisy-Chain Configuration in TRM.
If only one pad fails ISOCLKOUT shows fail. I don't recall other reason than missing power supply to some of the pads (for ex. vddshv[1:9] power rails ).
I would check all power supplies as close to the chip as I can. If all are good, then I would remove the SW 'wait' function to allow it to boot and then check all interfaces (at least one per power rail) to see which (if) are not operating thus to see which power rail is failing.

Regards,
Stan

0 Ren Bowei over 8 years ago in reply to Stanislav Stilyanov

Intellectual 650 points

Dear Stan,

I found this CPU module stucking in below source code after adding more debug messages.
==========================================================
clrsetbits_le32((*ctrl)->ctrl_core_sma_sw_0, CTRL_ISOLATE_MASK,
isolate << CTRL_ISOLATE_SHIFT);
==========================================================
In TRM section Isolation Requirements at page5400 (Section 18.4.6.1.6). The fail step is "4. Write 1 to the CTRL_CORE_SMA_SW_0[2] ISOLATE bit"
Do you know what causes it?

Best Regards,
Bowei Ren

0 Stanislav Stilyanov over 8 years ago in reply to Ren Bowei

TI__Mastermind 18030 points

Hi Bowei Ren,

Knowing that you have several identical boards with some of them failing and some good, I don't recall other issue than failing power supply. That includes cracked solder, cracked via or track, bad PMIC components (inductors or similar). Wrong power-up sequence (wrong OTP) may also cause the issue.

I would suggest you checking the power-up sequence for all power rails, as close to the SoC as possible. But starting point should be vddshv8, which powers the MMC1 IOs. This can cause isolation failing according to errata. Also, it's worth checking OTP of PMIC.

Regards,

Stan

Processors

Processors forum

Linux/DRA722: J6E boot up stucking in SPL