[RFC PATCH 00/16] arm: Add Rockchip RK3588 support

[Jagan Teki]

On Thu, 26 Jan 2023 at 22:28, Jonas Karlman <jonas at kwiboo.se> wrote:
>
> Hi Jagan,
> On 2023-01-26 17:51, Jagan Teki wrote:
> > Hi Jonas,
> >
> > On Thu, 26 Jan 2023 at 04:17, Jonas Karlman <jonas at kwiboo.se> wrote:
> >>
> >> Hi Jagan,
> >>
> >> On 2023-01-25 23:27, Jagan Teki wrote:
> >>> This series support Rockchip RK3588. All the device tree files are
> >>> synced from linux-next with the proper SHA1 mentioned in the commit
> >>> messages.
> >>>
> >>> Unfortunately, the BL31 from rkbin is not compatible with U-Boot so
> >>> it is failing to load ATF entry from SPL and hang.
> >>>
> >>> Verified below BL31 versions,
> >>>   bl31-v1.15
> >>>   bl31-v1.21
> >>>   bl31-v1.22
> >>>   bl31-v1.23
> >>>   bl31-v1.24
> >>>   bl31-v1.25
> >>>   bl31-v1.26
> >>>
> >>> Rever-engineered with respect to rockchip u-boot by using the same
> >>> FIT_GENERATOR being used in Mainline, rockchip u-boot is booting but
> >>> mainline showing the same issue.
> >>>
> >>> Log:
> >>>
> >>> LPDDR4X, 2112MHz01-00642-g6bdfd31756-dirty (Jan 26 2023 ���3:44:34 +0530)
> >>> channel[0] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
> >>> channel[1] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
> >>> channel[2] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
> >>> channel[3] BW=16 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=8 Size=4096MB
> >>> change to F1: 528MHz
> >>> change to F2: 1068MHz
> >>> change to F3: 1560MHz
> >>> change to F0: 2112MHz
> >>> out
> >>>
> >>> U-Boot SPL 2023.01-00642-g6bdfd31756-dirty (Jan 26 2023 - 03:44:34 +0530)
> >>> Trying to boot from MMC1
> >>> bl31_entry: atf_entry start
> >>> << hang >>
> >>>
> >>> Any information on BL31 for RK3588 please share.
> >>
> >> I had a similar strange booing issue with RK3568 and mainline U-Boot,
> >> turned out to be related to all parts of ATF not being properly loaded
> >> into PMU SRAM.
> >>
> >> Using my series at [1] I managed to get ATF to be fully loaded into
> >> PMU SRAM. Using CONFIG_SPL_FIT_SIGNATURE=y helped me finding out that
> >> the segment being loaded ended up corrupted.
> >>
> >> The use of 512 bytes alignment of the FIT helped mitigate that issue.
> >> Vendor U-Boot use a bounce buffer for all parts that is written into
> >> SRAM (anything loaded outside the gd->ram_base to gd->ram_top range).
> >>
> >> You can also find newer bl31 at [2], up to version v1.32.
> >>
> >> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=337891>>> [2] https://gitlab.com/rk3588_linux/rk/rkbin/-/tree/linux-5.10-gen-rkr3.5/bin/rk35>>
> > Thanks for the details. I did apply this set on the master. No change
> > in the behavior, used BL31 and ddr from [2] as well as in
> > rkbin/master.
>
> I did some tests on my Radxa ROCK 3 Model B with CONFIG_SPL_FIT_SIGNATURE=y
> and it looked like it failed to read data into memory, see below.
>
> It also looks like the sdhci compatible is not supported by the driver.
> Something that may need to be added to driver to properly read data?
>
>
> DDR V1.09 a930779e06 typ 22/11/21-17:50:56
> LPDDR4X, 2112MHz
> channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
> channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
> channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
> channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB
> Manufacturer ID:0x6
> CH0 RX Vref:31.7%, TX Vref:21.8%,20.8%
> CH1 RX Vref:31.7%, TX Vref:21.8%,21.8%
> CH2 RX Vref:32.7%, TX Vref:22.8%,21.8%
> CH3 RX Vref:32.7%, TX Vref:21.8%,20.8%
> change to F1: 528MHz
> change to F2: 1068MHz
> change to F3: 1560MHz
> change to F0: 2112MHz
> out
>
> U-Boot SPL 2023.01 (Jan 26 2023 - 00:24:53 +0000)
> Trying to boot from MMC1
> ## Checking hash(es) for config config_1 ... OK
> ## Checking hash(es) for Image atf_1 ... sha256 error!
> Bad hash value for 'hash' hash node in 'atf_1' image node
> mmc_load_image_raw_sector: mmc block read error
> Trying to boot from MMC1
> ## Checking hash(es) for config config_1 ... OK
> ## Checking hash(es) for Image atf_1 ... sha256 error!
> Bad hash value for 'hash' hash node in 'atf_1' image node

Look like this is something wrong with your patch series or master
changes on binman, not with the driver. I have observed the same if I
enable CONFIG_SPL_FIT_SIGNATURE.

Jagan.