[mwlinux]

Hi Gil,

try following code for tf-a.dts

&pinctrl_z {
i2c4_pins_z_mx: i2c4_mx-0 {
pins {
pinmux = <STM32_PINMUX(‘Z’, 4, AF6)>, /* I2C4_SCL */
<STM32_PINMUX(‘Z’, 5, AF6)>; /* I2C4_SDA */
bias-pull-up;
drive-open-drain;
slew-rate = <0>;
};
};

/* USER CODE BEGIN pinctrl_z */
/* USER CODE END pinctrl_z */
};

&i2c4{
pinctrl-names = “default”;
pinctrl-0 = <&i2c4_pins_z_mx>;
status = “okay”;

/* USER CODE BEGIN i2c4 */
i2c-scl-rising-time-ns = <185>;
i2c-scl-falling-time-ns = <20>;
clock-frequency = <400000>;

pmic: stpmic@33 {
compatible = “st,stpmic1”;
reg = <0x33>;
interrupts-extended = <&exti 55 IRQ_TYPE_EDGE_FALLING>;
interrupt-controller;
#interrupt-cells = <2>;
status = “okay”;
secure-status = “okay”;

regulators {
compatible = “st,stpmic1-regulators”;
buck1-supply = <&vin>;
buck2-supply = <&vin>;
buck3-supply = <&vin>;
buck4-supply = <&vin>;
ldo1-supply = <&v3v3>;
ldo2-supply = <&vin>;
ldo3-supply = <&vdd_ddr>;
ldo4-supply = <&vin>;
ldo5-supply = <&vin>;
ldo6-supply = <&v3v3>;
vref_ddr-supply = <&vin>;
boost-supply = <&vin>;
pwr_sw1-supply = <&bst_out>;
pwr_sw2-supply = <&bst_out>;

vddcore: buck1 {
regulator-name = “vddcore”;
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-initial-mode = <0>;
regulator-over-current-protection;
};

vdd_ddr: buck2 {
regulator-name = “vdd_ddr”;
regulator-min-microvolt = <1350000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-initial-mode = <0>;
regulator-over-current-protection;
};

vdd: buck3 {
regulator-name = “vdd”;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
st,mask-reset;
regulator-initial-mode = <0>;
regulator-over-current-protection;
};

v3v3: buck4 {
regulator-name = “v3v3”;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-over-current-protection;
regulator-initial-mode = <0>;
};

v1v8_audio: ldo1 {
regulator-name = “v1v8_audio”;
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};

v3v3_hdmi: ldo2 {
regulator-name = “v3v3_hdmi”;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};

vtt_ddr: ldo3 {
regulator-name = “vtt_ddr”;
regulator-always-on;
regulator-over-current-protection;
st,regulator-sink-source;
};

vdd_usb: ldo4 {
regulator-name = “vdd_usb”;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};

vdda: ldo5 {
regulator-name = “vdda”;
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <2500000>;
//regulator-boot-on;
regulator-always-on;
};

v1v2_hdmi: ldo6 {
regulator-name = “v1v2_hdmi”;
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};

vref_ddr: vref_ddr {
regulator-name = “vref_ddr”;
regulator-always-on;
};

bst_out: boost {
regulator-name = “bst_out”;
};

vbus_otg: pwr_sw1 {
regulator-name = “vbus_otg”;
};

vbus_sw: pwr_sw2 {
regulator-name = “vbus_sw”;
regulator-active-discharge = <1>;
};
};
};
/* USER CODE END i2c4 */
};

This is correct that the voltage for DDR is turned off. The first stage bootloader should put on and configure DDR memory to work then load the second bootloader code into DDR memory and jump to the second bootloader (usually U-Boot). Why is DDR turned off, the answer is the CPU doesn’t know what kind of memory is connected 1.8V, 1.5V or maybe 1.35V. In the first stage bootloader, we decide what kind of memory is connected and how to configure it properly.

BR Michal

• This reply was modified 4 months, 2 weeks ago by mwlinux.
• This reply was modified 4 months, 2 weeks ago by mwlinux.
• This reply was modified 4 months, 2 weeks ago by mwlinux.

[mwlinux]

Maybe this one is missing

mmc bootpart enable 1 1 /dev/mmcblk1

1	mmc bootpart enable 1 1 /dev/mmcblk1

BR Michal

[mwlinux]

In the U-Boot, everything looks good but during the system bring up I can’t see mmc initialization. Check sdmmc section in dts for the kernel. The next thing is NFS, I saw some records in the log, maybe You used NFS rootfs loading previously and forgot to change to mmc.

BR Michal

[mwlinux]

Hi,

You need to change in boot partition a following record

APPEND root=PARTUUID=491f6117-415d-4f53-88c9-6e0de54deac6 rootwait rw   console=${console},${baudrate}

to

APPEND root=root=/dev/mmcblk0p8 rootwait rw   console=${console},${baudrate}

I do not remember which number is the rootfs partition, it can be 7 or 8 or 9 You need to test or check.

Of course on the boot partition, You find two folders mmc0_extlinux and mmc1_extlinux everything depends on Your configuration.

BR Michal

 

[mwlinux]

Hi gil_he

first what You need to do is unlock the partitions

echo 0 > /sys/class/block/mmcblk1boot0/force_ro

echo 0 > /sys/class/block/mmcblk1boot1/force_ro

and then type

dd if=USB/tf-a-stm32mp157f-ev1-emmc.stm32 of=/dev/mmcblk1boot0 conv=fdatasync

dd if=USB/tf-a-stm32mp157f-ev1-emmc.stm32 of=/dev/mmcblk1boot1 conv=fdatasync

If You want to do this from U-Boot it is necessary to use STM32 Cube Programmer to write the first and second-stage USB U-Boot and via debug UART stop U-Boot execution. Next in the stopped U-Boot console ums 0 mmc 0 or ums 0 mmc 1 and the memory will be visible from Your host computer.

So You can from the host do the same as above

dd if=USB/tf-a-stm32mp157f-ev1-emmc.stm32 of=/dev/mmcblk1boot0 conv=fdatasync

Of course, remember to align memory id ‘/dev/mmcblk1boot0‘

I hope to help You a little bit.

BR Michal

[mwlinux]

Hi Gil,

yes, I used the presented profile for this chip, but everything depends on Your soldering machine. I suggest the last phase change to 20 seconds. Nevertheless, remember to bake chips before soldering and adopt the profile to Your board and Your soldering machine. I can’t guarantee success, I made a few tests after achieving a good result.

BR

Michal

[mwlinux]

I have broken about five pcs in the same way. If it is possible, I can send that pieces for investigation.

BR Michal

[mwlinux]

Neeraj,

I think that baking is not a problem because after achieving a shortcut in 5V to GND and again reballing (reablling I mean chip on back, balls and hot-air) shortcut disappears. But again soldering causes a shortcut between 5V to GND. After such rebaling procedure 1 at 10 times, osd32 is back to normal work. So I guess that some lead material is sometimes short sometimes doesn’t. But this is only my feeling nothing else, I’m not an expert with soldering.

BR

Michal

[mwlinux]

Hi,

with new pieces and a soldering IR station machine with profile, I have no issue.

[mwlinux]

Hi Gil_he,

a very difficult thing to do. Don’t use any hot-air stuff. I have broken a few OSD the final result shortcuts 5V to GND inside the chip. The only good way is reballing machine with the profile plus new OSD32 with fabric balls. I suggest something like below

The bottom heater is set to 150C

The upper IR heater profile as follow

It is good on my machine. Sometimes I need to do this process twice, and I don’t know why.

Fabric pieces have balls on pads if You make reballing You need to set balls on PCB. I make a few experiments to give OSD32… on back than stencil + balls and rebaling machine or hotair to solder the balls. This process finished quite good, but when I figurated OSD32… on PCB and even used reballing machine with a good profile always achieved shortcuts on 5Vto GND. It is very strange I have had no issue like this before. This chip is very complicated inside, nano PCB with the IP cores. I feel that some lead during increased temperature leakage on neighbour pads makes shortcuts, of course, inside the chip. I don’t recommend reballing for this OSD32.

• This reply was modified 2 years, 2 months ago by mwlinux.
• This reply was modified 2 years, 2 months ago by mwlinux.

[Author]

Posts