Boot error with linaro openembedded

Products Support Qualcomm RB5
, ,
#1

Hi!
I’m trying to use the Qualcomm RB5 on our application with Yocto.

i Donwload and compiled with this repository but failed.

https://releases.linaro.org/96boards/rb5/linaro/openembedded/21.04/

it shows Only
‘Kernel panic - not syncing: VFS: Unable to mount rootfs’ messasges

Also i tried Bootloader with

https://releases.linaro.org/96boards/rb5/linaro/rescue/21.04/

but it also failed with showing error message

 Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.XF.3.2-00310-SM8250-1
S - IMAGE_VARIANT_STRING=Soc8250LAA
S - OEM_IMAGE_VERSION_STRING=7d042e14209b
S - Boot Interface: UFS
S - Secure Boot: Off
S - Boot Config @ 0x00786070 = 0x00000001
S - JTAG ID @ 0x00786130 = 0x0015a0e1
S - OEM ID @ 0x00786138 = 0x00000000
S - Serial Number @ 0x00786134 = 0xbef60f07
S - OEM Config Row 0 @ 0x007841e0 = 0x0000000000000000
S - OEM Config Row 1 @ 0x007841e8 = 0x0000000000000000
S - Feature Config Row 0 @ 0x007841f8 = 0x0040200000000400
S - Feature Config Row 1 @ 0x00784200 = 0xc000000000000000
S - Core 0 Frequency, 1516 MHz
S - PBL Patch Ver: 5
S - PBL freq: 600 MHZ
D -      6208 - pbl_apps_init_timestamp
D -     31693 - bootable_media_detect_timestamp
D -       974 - bl_elf_metadata_loading_timestamp
D -       712 - bl_hash_seg_auth_timestamp
D -      6265 - bl_elf_loadable_segment_loading_timestamp
D -      5502 - bl_elf_segs_hash_verify_timestamp
D -      7018 - bl_sec_hash_seg_auth_timestamp
D -       819 - bl_sec_segs_hash_verify_timestamp
D -        34 - pbl_populate_shared_data_and_exit_timestamp
S -     59225 - PBL, End
B -     72864 - SBL1, Start
B -    187636 - SBL1 BUILD @ 04:29:03 on Mar 20 2021
B -    191784 - usb: usb_shared_hs_phy_init: hs phy cfg size , 0xc
D -     10584 - sbl1_hw_init
D -         0 - boot_flash_init
B -    267454 - UFS INQUIRY ID: SAMSUNG KLUDG4UHDB-B2D1 0900
B -    268949 - UFS Boot LUN: 1
D -       915 - Auth Metadata
D -     79513 - sbl1_xblconfig_init
D -         0 - boot_config_data_table_default_init
B -    288469 - Using default CDT
D -      4727 - boot_config_data_table_init
B -    296246 - CDT Version:3,Platform ID:8,Major ID:1,Minor ID:0,Subtype:0
D -     17294 - sbl1_hw_platform_pre_ddr
D -        30 - devcfg init
B -    325130 - PM: PM 0=0x400008000000040:0x0 
B -    325221 - PM: PM 1=0x400008000000040:0x0 
B -    329583 - PM: PM 2=0x400008000000020:0x0 
B -    333944 - PM: PM 5=0x400000000000000:0x0 
B -    338306 - PM: POWER ON by CBLPWR,POWER OFF by RAW_XVDD_SHD
B -    450027 - PM: SET_VAL:Skip
B -    450485 - PM: PSI: b0x00_v0x53
B -    456646 - PM: Device Init # SPMI Transn: 5217
B -    456646 - Mem dump cmd, entry
D -         0 - Mem dump cmd, exit
B -    464698 - Error code 22000080 at sbl1_hw.c Line 547
B -    467931 - ^^^^- Printing Call Stack -^^^^
B -    473207 - func_addr  :   148171A8
B -    477569 - func_addr  :   14824064
B -    481229 - func_addr  :   14824120
B -    484889 - func_addr  :   1482466C
B -    488579 - func_addr  :   1481584C
B -    492239 - ^^^^^- Done Printing -^^^^^
B -    495899 - sbl_error_handler FAIL: DDR not initialized

Any solution for this??
I tried to fix with thundercomm’s recovery image, but still same problem.

#2

What did you compile? Have you generated your own image from OE, or have you flashed the prebuilt rpb images (boot + rootfs)?

#3

Yes, unfortunately this is an expected issue, we have changed the partition scheme, so this release requires updating the rescue/partition scheme/bootloader as well, as stated in the release notes.

This shows that your board is flashed with the wrong CDT (Platform ID). We have the fix ready and we are now waiting for the permission from the Qualcomm (or Thundercomm) to release it.

#4

I compiled boot and rootfs both.
precompiled are working well but even just repo sync and bitbake result is not working

#5

i borrow the DEV board end of last year, it was working well but latest version and also the old version has same error.( i try to change the .bb file to old one )

When would be the release that expacted?
2 of board is same status and need to know get another board or wait.
thanks

#6

Hi, any news on the update referenced here? I’m seeing the same issue.

#7

me too, how to fix this issue? it is the bootloader issue?

#8

any update on new bootloader?

#9

Any update yet…still not working with bootloader

#10

I am still waiting for the feedback from the liaro and thundercomm, but no any response, seems they don’t know how to fix it.
I used their latest bootloader released on 5th. May, after that, the issue is the same. also the recovery procedure cannont make RB5 back.

#11

hey!

no, we know how to fix, and understand the problem… and we’ve tested the fix. But it requires a redistribution of a proprietary firmware blob (cdt) and we are waiting for a proper release to us, so that we can fix the builds.

Some RB5 devices are not “properly” flashed during production (it might be a batch, or an initial series…) and some devices are flashed with the right cdb blob already…

We are tracking this item carefully with QCOM and TCOM… and it will hopefully be resolved shortly.

#12

Hi ndec,
I have recovered RB5 with the help of TCOM, now I have another question:
Do you know how to replace the current Debian Linux kernel image with my own complied v5.12 kernel image?

I used to just copy my kernel image to /boot folder, then modify the grub.conf, but for RB5, it uses Debian+UEFI, I have no idea, how to replace its kernel image with my own kernel.

do you have any ideas?

#13

How did you install Debian on the RB5?
Since you mention grub, can you please share a bit more information about your setup as well? and how you boot the device so far?

#14

How did you recovered bootloader??
Any specific method can do??

#15

I following the Tcom instructions, re-flash the bootloader, but bootloader images are provide by TCOM.
after that, RB5 will directly go to fastboot mode, then I flash the boot and rootfs images.
the boot and rootfs are from here: Linaro Snapshots

Note: Bootloader provided by Linaro, still has the issue, means after recovering the RB5, I flash the bootloader from Linaro Snapshots. the original issue will come back again. So, I am now use the Tcom’s bootloader image.

#16

I think it is better to contact Tcom. you need a special tool to erase the UFS and reflash.

#17

Hi Ndec,
RB5 doesn’t use grub, right?
Do you have experience with how to replace the Debian kernel image with my own cross-compiled kernel image?

#18

the Linaro rescue package also erases the UFS and reflash. The tool QDL is doing that. The concern we have is that 1 file that needs to be flashed was missed in the firmware release, and is not flashed. Once that file is released to us, the Linaro rescue package will work just fine.

#19

thanks for the explanation, so you are using our custom debian images then. And you’re right grub is not used.

The boot process is the following:

  1. the SoC runs the initial bootloader (ROM code) called PBL, and it loads the secondary bootloader, called XBL. It loads this file from the ‘xbl’ partition in UFS.
  2. xbl initializes the platform and DDR (among other things) and loads the next stage bootloader, EDK2/UEFI or “ABL”
  3. ABL loads the boot image from the boot image, which is expected to contain the compressed kernel image, the DTB (and optionnally an initramfs). then ABL jumps to the kernel.
  4. the kernel boots, it uses (or not) an initramfs, and eventually mount the actual root file system on UFS, and modules are loaded from there.

If you build your own kernel then you notice that the new kernel modules need to be installed in the root fs, and the kernel image is in the boot image!

WE have some high level instructions to help use a locally built kernel in the RB3 release notes (we haven’t made a release for Debian for RB5 yet!), but the RB3 instructions will work on RB5 too. Search for “Building the Linux kernel from source” here http://releases.linaro.org/96boards/dragonboard845c/linaro/debian/latest/

#20

@jackyard we are having this same issue. We have emailed TComm about getting our hands on the UFS erase tool & their bootloader, still waiting on a response. With the TComm bootloader are you able to get the linaro kernel booting, or is the kernel still limited to the one shipping with sdkmanager?