Hi Simon, On Fri, 27 Jan 2023 at 00:45, Simon Glass <s...@chromium.org> wrote: > > Hi Jagan, > > On Thu, 26 Jan 2023 at 11:27, Jagan Teki <ja...@edgeble.ai> wrote: > > > > Hi Simon, > > > > On Thu, 26 Jan 2023 at 23:34, Simon Glass <s...@chromium.org> wrote: > > > > > > Hi Jagan, > > > > > > On Thu, 26 Jan 2023 at 10:42, Jagan Teki <ja...@edgeble.ai> wrote: > > > > > > > > On Thu, 26 Jan 2023 at 22:28, Jonas Karlman <jo...@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 <jo...@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. > > > > > > There are some more changes in dm/master that I'm about to pull in. > > > One of them from Jonas Karlman adds hash nodes so may be involved. > > > > I found the same issue on the dm/master > > > > U-Boot SPL 2023.01-00176-gb21fb7a9c0 (Jan 26 2023 - 23:55:11 +0530) > > 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 > > SPL: failed to boot from all boot devices > > ### ERROR ### Please RESET the board ### > > Is the FIT image broken? You can use check_sign or dump_image to see.
This seems okay, let me know if you see any issue. > ./tools/fit_check_sign -f u-boot.itb -k > arch/arm/dts/rk3588-edgeble-neu6a-io.dtb Verifying Hash Integrity for node 'config-1'... Verified OK, loading images ## Loading kernel from FIT Image at 7f98532c7000 ... Using 'config-1' configuration Verifying Hash Integrity ... OK Could not find subimage node type 'kernel' ## Loading fdt from FIT Image at 7f98532c7000 ... Using 'config-1' configuration Verifying Hash Integrity ... OK Trying 'fdt-1' fdt subimage Description: fdt-rk3588-edgeble-neu6a-io Created: Fri Jan 27 01:01:31 2023 Type: Flat Device Tree Compression: uncompressed Data Size: 41408 Bytes = 40.44 KiB = 0.04 MiB Architecture: Unknown Architecture Hash algo: sha256 Hash value: a5de5505624412d216c6e985fb3669e84785b3675765bc85f08d8b0dbeffdbd7 Verifying Hash Integrity ... sha256+ OK Decrypting Data ... OK Loading Flat Device Tree ## Loading ramdisk from FIT Image at 7f98532c7000 ... Using 'config-1' configuration Verifying Hash Integrity ... OK Could not find subimage node type 'ramdisk' Signature check OK Thanks, Jagan.