News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

TE0803 unable to boot up on custom board

Started by joseer, February 05, 2020, 04:29:06 PM

Previous topic - Next topic

joseer

Hello,

I've got the TE0803 module mounted on a custom carrier board, I'm using a CPLD to boot up the module (same CPLD and approach as in the TEBF0808 carrier).

I've followed the sequence described at the figure 4 here: https://wiki.trenz-electronic.de/display/PD/TE0803+TRM#TE0803TRM-PowerandPower-OnSequence and also I based my design on the CPLD supplied code, the only difference is that instead having 3 different state machines (PS, PWR, PL) I'm having one for all enable and good signals.

The sequence goes well till reach the last step where GTR and PLL pwr are enabled (EN_PSGTR EN_PLL), the problem is that after enable those I've got the good signals equal to 0. The rest of the good signals are fine (on high level).

The snipet code is:

     STAT_PWR : process( current_state )
begin
   case current_state is
      when IDLE =>
         
         mod_en      <='0';
         en_1v8      <='0';
         per_en      <='0';

         en_lpd      <='0';
         en_fpd      <='0';
         en_ddr      <='0';
         en_psgt     <='0';
         en_pll_pwr  <='0';

         en_pl       <='0';
         en_gt_r     <='0';
         en_gt_l     <='0';

         next_state <= MOD_ON;
         pwr_rdy     <='0';

      when MOD_ON =>

         mod_en      <='1';
         en_1v8      <='0';
         per_en      <='0';

         en_lpd      <='0';
         en_fpd      <='0';
         en_ddr      <='0';
         en_psgt     <='0';
         en_pll_pwr  <='0';

         en_pl       <='0';
         en_gt_r     <='0';
         en_gt_l     <='0';

         next_state <= MOD_LPD_PL_ON;
         pwr_rdy     <='0';

      when MOD_LPD_PL_ON =>

         mod_en      <='1';
         en_1v8      <='0';
         per_en      <='0';

         en_lpd      <='1';
         en_fpd      <='0';
         en_ddr      <='0';
         en_psgt     <='0';
         en_pll_pwr  <='0';

         en_pl       <='0';
         en_gt_r     <='0';
         en_gt_l     <='0';

         if (lp_good = '1') then
            next_state <= MOD_FPD_ON;
         else
            next_state <= MOD_LPD_PL_ON;
         end if ;
         
         pwr_rdy     <='0';

      when MOD_FPD_ON =>

         mod_en      <='1';
         en_1v8      <='0';
         per_en      <='0';

         en_lpd      <='1';
         en_fpd      <='1';
         en_ddr      <='0';
         en_psgt     <='0';
         en_pll_pwr  <='0';

         en_pl       <='1';
         en_gt_r     <='1';
         en_gt_l     <='1';

         if (pg_fpd = '1' and pg_pl = '1' and pg_gt_r = '1' and pg_gt_l = '1') then
            next_state <= MOD_PS_ON;
         else
            next_state <= MOD_FPD_ON;
         end if ;
         pwr_rdy     <='0';
         
      when MOD_PS_ON =>

         mod_en      <='1';
         en_1v8      <='0';
         per_en      <='0';

         en_lpd      <='1';
         en_fpd      <='1';
         en_ddr      <='1';
         en_psgt     <='1';
         en_pll_pwr  <='1';

         en_pl       <='1';
         en_gt_r     <='1';
         en_gt_l     <='1';


         if (pg_ddr = '1' and pg_psgt = '1' and pg_pll = '1') then  <<=== STOPS HERE: pg_ddr =1 pg_psgt=0  pg_pll=0
            next_state <= V18_ON;
         else
            next_state <= MOD_PS_ON;
         end if ;
         pwr_rdy     <='0';


Any idea why these PG signals (PG_PSGTR PG_PLL) could be held to 0?

Thanks in advance.

JH

Hi,
which assembly version of TE0803 did you use? With or without GTH (ZU4 or higher)?GTH power regulators are not assembled for this modules without GTH. And there is also no pull up on the module for PG_GT_R, so enable pullup on your cpld for this pin.


PG_PL should be pullup with PC_DCIN if power is good.
br
John

joseer

Hi John,

Thanks for your answer, the module is TE0803-04EV-1EA ( VCU).
I pulled up the all PG signals as is highlighted in the power up sequence section of the TRM , and now they come high fine.

But still a problem with the PG_PLL_1V8 signal which remains in 0. I checked in the module schematic: https://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/Modules_and_Module_Carriers/5.2x7.6/TE0803/REV02/Documents/SCH-TE0803-02-04EV-1EA.PDF

and it seems that the PLL pins are not used (J2.80/J2.77), should I ignore the PG_PLL_1V8 and EN_PLL_PWR signals?

Anyway (removing those two signals) still not booting and the module red LED remains on. I checked the error signals (ERR_OUT/ERR_STAT) and both are high.

Any ideas  what is going on?

JH

PG_PLL_1V8 is for TE0808 and not needed for TE0803 --> add dummy pullup property on your CPLD so you are still compatible

where did you try to boot? QSPI or SD? Do you use a valid design?

At first set boot mode to jtag and check if you see PL and PS on Vivado HW manager.

To check where your FSBL stops(in case Boot Mode and DDR setup is correct), enable debug flags for zynqMP on your PLL and see what's happens on uart.


br
John

joseer

#4
Hi John,

Yes, I'm trying to boot using SD and checking the uart output it looks like I have to change/modify quite a few options at the fsbl to make it compatible with my board.

First thing I did is to comment the I2C switch stuff as it was stopping at that point. Now goes further and the red light comes off but I still having a few issues more like mmc (I have not mmc on my board), GEM PHY (I've got ethernet implemented same config as tebf0808)...etc, I'm going to dig more into the fsbl code and see if I can make it boot 100%.

The boot log I've got so far is:

--------------------------------------------------------------------------------
TE0803 TE_XFsbl_HookPsuInit_Custom
USB Reset Complete
PCIe Reset Complete

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Xilinx Zynq MP First Stage Boot Loader (TE modified)
Release 2018.3   Feb  6 2020  -  14:35:25
Device Name: XCZU4EV

--------------------------------------------------------------------------------
TE0803 TE_XFsbl_BoardInit_Custom
GTR Lane0 LOCK Status failed. (Reg:0xFD4023E4,Val:0x1)
GTR Lane1 LOCK Status failed. (Reg:0xFD4063E4,Val:0x1)
GTR Lane3 LOCK Status failed. (Reg:0xFD40E3E4,Val:0x1)
Configure Carrier I2C Switch 0x73 for EEPROM access
Error: Configure Carrier I2C Switch 0x73
NOTICE:  ATF running on XCZU4EV/silicon v4/RTL5.1 at 0xfffea000
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x8000000
NOTICE:  BL31: v1.5(release):xilinx-v2018.2-919-g08560c36
NOTICE:  BL31: Built : 12:52:23, Jan 31 2020
PMUFW:  v1.1


U-Boot 2018.01 (Jan 31 2020 - 12:54:36 +0000) Xilinx ZynqMP ZCU102 rev1.0

I2C:   ready
DRAM:  2 GiB
EL Level:       EL2
Chip ID:        zu4ev
MMC:   Card did not respond to voltage select!
mmc_init: -95, time 26
mmc@ff160000 - probe failed: -95
Card did not respond to voltage select!
mmc_init: -95, time 27

Using default environment

In:    serial@ff000000
Out:   serial@ff000000
Err:   serial@ff000000
Board: Xilinx ZynqMP
Bootmode: SD_MODE1
Net:   ZYNQ GEM: ff0e0000, phyaddr 1, interface rgmii-id
PHY is not detected
GEM PHY init failed
No ethernet found.
U-BOOT for petalinux

ZYNQ GEM: ff0e0000, phyaddr 1, interface rgmii-id
mdio_register: non unique device name 'eth0'
ZYNQ GEM: ff0e0000, phyaddr 1, interface rgmii-id
mdio_register: non unique device name 'eth0'
ZYNQ GEM: ff0e0000, phyaddr 1, interface rgmii-id
mdio_register: non unique device name 'eth0'
ZYNQ GEM: ff0e0000, phyaddr 1, interface rgmii-id
mdio_register: non unique device name 'eth0'
No ethernet found.
ZYNQ GEM: ff0e0000, phyaddr 1, interface rgmii-id
mdio_register: non unique device name 'eth0'
Hit any key to stop autoboot:  0
no mmc device at slot 0
ZynqMP>


Thanks

JH

Hi,

you should start with test_board design and enable the interfaces you has on your own carrier (at first without GTR (PCIe,USB3,SATA,DP), that's mostly easier and did not SI PLL CLKs which must be initialised with FSBL(example in the starterkit) ). --> that's cleaner. In case you use some similar interfaces like on starterkit, you can check documentation what we has enabled in linux for these interfaces or if it's done automatically by xsa/hdf import.


br
John

joseer

Hi,

Thanks for the advice, I went through all of that process (creating new simple vivado and petalinux TE based projects to test the board) and it seems that now detects the devices, but unfortunately the boot seems to stop at the point when is not detecting emmc.

The boot mode config on the CPLD is:

mode0          <= '1';
mode1          <= '0';
mode2          <= '1';
mode3          <= '0'; 


Which is SD1 and this is the output log:

--------------------------------------------------------------------------------
TE0803 TE_XFsbl_HookPsuInit_Custom
USB Reset Complete
PCIe Reset Complete

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Xilinx Zynq MP First Stage Boot Loader (TE modified)
Release 2018.3   Feb  7 2020  -  10:45:10
Device Name: XCZU4EV

--------------------------------------------------------------------------------
TE0803 TE_XFsbl_BoardInit_Custom
GTR Lane0 LOCK Status failed. (Reg:0xFD4023E4,Val:0x1)
GTR Lane1 LOCK Status failed. (Reg:0xFD4063E4,Val:0x1)
GTR Lane2 LOCK Status failed. (Reg:0xFD40A3E4,Val:0x1)
GTR Lane3 LOCK Status failed. (Reg:0xFD40E3E4,Val:0x1)
Configure Carrier I2C Switch 0x73 for EEPROM access
Error: Configure Carrier I2C Switch 0x73
NOTICE:  ATF running on XCZU4EV/silicon v4/RTL5.1 at 0xfffea000
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x8000000
NOTICE:  BL31: v1.5(release):xilinx-v2018.2-919-g08560c36
NOTICE:  BL31: Built : 10:06:08, Feb  7 2020
PMUFW:  v1.1


U-Boot 2018.01 (Feb 07 2020 - 10:07:23 +0000) Xilinx ZynqMP ZCU102 rev1.0

I2C:   ready
DRAM:  2 GiB
EL Level:       EL2
Chip ID:        zu4ev
MMC:   sdhci_send_command: MMC: 0 busy timeout increasing to: 200 ms.
sdhci_send_command: MMC: 0 busy timeout increasing to: 400 ms.
sdhci_send_command: MMC: 0 busy timeout increasing to: 800 ms.
sdhci_send_command: MMC: 0 busy timeout increasing to: 1600 ms.
sdhci_send_command: MMC: 0 busy timeout increasing to: 3200 ms.
sdhci_send_command: MMC: 0 busy timeout.
sdhci_send_command: MMC: 0 busy timeout.
mmc_init: -70, time 7439
mmc@ff160000 - probe failed: -70
sdhci_send_command: MMC: 0 busy timeout.
sdhci_send_command: MMC: 0 busy timeout.
mmc_init: -70, time 7413

Using default environment

In:    serial@ff000000
Out:   serial@ff000000
Err:   serial@ff000000
Board: Xilinx ZynqMP
Bootmode: SD_MODE1
Net:   ZYNQ GEM: ff0e0000, phyaddr 1, interface rgmii-id

Warning: ethernet@ff0e0000 using MAC address from ROM
eth0: ethernet@ff0e0000
U-BOOT for petalinux

ethernet@ff0e0000 Waiting for PHY auto negotiation to complete......................................... TIMEOUT !
Hit any key to stop autoboot:  0
no mmc device at slot 0
ZynqMP>


Any idea why could it be stopping at that point?

Thanks


JH

Hi,
what did you connect on mmc@ff160000?
Should be SD0 controller.
On TEBF0808 we add there EMMC and use SD1 for SD. In case you has both enabled, select SD1 in linux:
https://wiki.trenz-electronic.de/display/PD/TE0803+StarterKit#TE0803StarterKit-Config
for SD see also device tree changes.
br
John

joseer

#8
Hi,

Thanks for your reply and help,

I've got already selected SD1 as primary boot:

CONFIG_SUBSYSTEM_PRIMARY_SD_PSU_SD_1_SELECT=y

Also the input at the DT:

&sdhci1 {
//disable-wp;
no-1-8-v;

};


Sorry, I don't understand what you meant with the mmc@ff160000 connection could you explain it please?, 
On my board there're only two SD card slots (no emmc), the SD1 (copy from TEBF808) and SD0 which is connected through EMIO and its not being used at the moment,
do you think that its trying to boot from SD0 instead? (the boot log shows that is SD1 the selected one)
Is it not possible to boot without eMMC?

JH

Hi,
uboot try to get access to SD0(mmc@ff160000) and got error. disable interfaces which are not available and regenerate linux.
br
John

joseer

Hi,

I tried to disable the SD0 in the DT (like that force it to boot from SD1):

&sdhci0 {
status = "disabled";
};


And now I've got:


U-Boot 2018.01 (Feb 07 2020 - 14:26:17 +0000) Xilinx ZynqMP ZCU102 rev1.0

I2C:   ready
DRAM:  2 GiB
EL Level:       EL2
Chip ID:        zu4ev
MMC:   mmc@ff170000: 0 (SD)
Using default environment

In:    serial@ff000000
Out:   serial@ff000000
Err:   serial@ff000000
Board: Xilinx ZynqMP
Bootmode: SD_MODE1
Net:   ZYNQ GEM: ff0e0000, phyaddr 1, interface rgmii-id

Warning: ethernet@ff0e0000 using MAC address from ROM
eth0: ethernet@ff0e0000
U-BOOT for petalinux

ethernet@ff0e0000 Waiting for PHY auto negotiation to complete......................................... TIMEOUT !
Hit any key to stop autoboot:  0
** Bad device mmc 1 **
Device: mmc@ff170000
Manufacturer ID: 3
OEM: 5344
Name: SC128
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 119.1 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
** Bad device mmc 1 **


Any idea why is coming this error?

Just to clarify, the SD card is the same I'm using to boot with TEBF0808..

thanks

joseer

I've finally managed to get it working, it wasn't straight forward though, I had to copy from the platform-auto.h file the line: #define CONFIG_EXTRA_ENV_SETTINGS \...... to platform-top.h and modify the line cp_kernel2ram  removing mmcinfo and adding mmc 1.
Now petalinux boots fine from SD1 without need to disable SD0 just in case we use it in future.

JH

This should be set normally correctly when you change petalinux config (CONFIG_SUBSYSTEM_PRIMARY_SD_PSU_SD_1_SELECT=y), maybe something was not proper updated (this sometimes happens, in doubt I create the project always once completely new).
But result is the same, good to hear that it works now.

br
John

joseer

Hi,

Quote from: JH on February 10, 2020, 08:40:43 AM
This should be set normally correctly when you change petalinux config (CONFIG_SUBSYSTEM_PRIMARY_SD_PSU_SD_1_SELECT=y), maybe something was not proper updated (this sometimes happens, in doubt I create the project always once completely new).

Yes, the petalinux config flag wasn't updated for some reason, so I had to modify the platform-top.h file.


On the other hand I'm testing now USB3 interface (which is a exact copy from TEBF0808) with a USB3 camera. I'm seeing a strange behaviour in regards to plug and unplug detection, the camera gets detected and it works perfectly in the next two situations:

- Boot the board (custom carrier+TE0803) with the camera plugged in. Suspend HUB LED comes off.
- Boot the board, and after connect the camera. Suspend HUB LED also comes off.

The problem comes when in any of the above situations after the camera has been detected if I unplug it, linux doesn't detect that the camera has been disconnected (LED remains off) and from this point if I plug it back it won't be detected again.

I would thought that the connect/disconnect should be managed by the usb protocol so I'm not able to figure out what I'm missing...

Any idea or clue what could it be the issue?

Thanks.

JH

Hi, this also happens with normal USB mass storages?
br
John

joseer

Yes, any USB3 device. Anyway the camera disconnection is working in the TEBF0808 .I double checked HW layout and config. and everything looks identical....
Thanks

JH

Hi,
you say "exact copy" so also same manufacturer components?
Which kind of resistor did you use for VBUS on your USB 2 PHY?

We have changed it one time to 1kOhm :
https://wiki.trenz-electronic.de/display/PD/PCN-20190502+TEBF0808-04+to+TEBF0808-04A+Hardware+Revision+Change

br
John

joseer

#17
Quote from: JH on February 12, 2020, 02:44:55 PM
Hi,
you say "exact copy" so also same manufacturer components?
Which kind of resistor did you use for VBUS on your USB 2 PHY?

Hi, thanks for the reply, yes the resistor is 1k 1% I must have something wrong but after checking all components I can't see clearly the issue, when the device is detected it works fine....

In terms of the manufacturers, now you mentioned I compared the boot logs (custom board/TEBF0808):

TEBF0808:

[    6.142645] usb 1-1.4: New USB device found, idVendor=2109, idProduct=2811
[    6.149544] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    6.177339] hub 1-1.4:1.0: USB hub found
[    6.181422] hub 1-1.4:1.0: 4 ports detected


The custom board:

[    5.568535] usb 2-1: New USB device found, idVendor=04b4, idProduct=6508
[    5.575239] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    5.628641] hub 2-1:1.0: USB hub found
[    5.632606] hub 2-1:1.0: 4 ports detected


(Please find more boot log info attached)


Do you think that could it be this the problem? theoretically are same devices (USB3320C-EZK for the PHY and CYUSB3324 for the HUB) the devices I'm using are:

This is the HUB: https://www.digikey.co.uk/products/en?keywords=428-3373-ND
And this is the USB2 PHY: https://www.digikey.co.uk/products/en?keywords=USB3320C-EZK-ND



JH

Do you use the same device tree like we:
https://wiki.trenz-electronic.de/display/PD/TE0808+StarterKit#TE0808StarterKit-DeviceTree

here are some information:
https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/usb/dwc3.txt

it's a little bit try and error, at the end it depends on drivers from xilinx which property is  really use. You should try out 19.2 Vivis/Vivado/petalinux in case you use another version.
When you change something on linux setup, I would recommend to clean your project, so that it will be update your changes (it can happens that not all changes are recognized, when you not clear your project)

Maybe it's also some HW problem of only one of your board?  Do you have an second board of your carrier to test if it shows the same behaivior?

br
John

joseer

Hi John,

Thanks for your answer, I'll have a look to the info.

My DT is base on the same one as you pointed the only difference is that I have removed QSPI and I2C entries since I'm not using them.

The weird thing (or the thing confuse me more) is that everything else works fine, and the camera connection event gets detected (I can see it in the dmesg) but when unplugged is not being detected also the device still in the lsusb list...

Quote from: JH on February 13, 2020, 11:38:00 AM
Maybe it's also some HW problem of only one of your board?  Do you have an second board of your carrier to test if it shows the same behaivior?
Yes, I'm starting thinking that it could be a hardware issue on the board so I'll get a try with a second fresh one and see if the problem persist.