Hello,

We noticed a difference between PetaLinux 2022.2 and meta-xilinx. When using 
petalinux-package to create a boot image for ZynqMP, it seems that the .bif 
that is generated uses the CBR method of loading PMU FW, as described here: 
https://docs.xilinx.com/r/en-US/ug1137-zynq-ultrascale-mpsoc-swdev/PMU-Firmware-Loading-Options.

Contrast this to meta-xilinx (2022.2) which uses the FSBL method. We noticed 
that when building BOOT.BIN using PetaLinux, everything works fine. When using 
Yocto, we end up with PS_ERROR_OUT asserting and our red LED turning on. (This 
is a custom board).

I used a JTAG to check the source of the error when booting using the 
Yocto-built BOOT.BIN. The output is below:

xsct% rrd pmu_global
            global_cntrl: 00018812                  ps_cntrl: 00000000
     apu_pwr_status_init: 00000000                 mem_cntrl: 00bb02cb
       addr_error_status: 00000000       addr_error_int_mask: 00000001
       addr_error_int_en                  addr_error_int_dis
     global_gen_storage0: 00000000       global_gen_storage1: 00000000
     global_gen_storage2: 00000000       global_gen_storage3: 00000000
     global_gen_storage4: 00000006       global_gen_storage5: 00020003
     global_gen_storage6: fffe9e00    pers_glob_gen_storage0: 00000000
  pers_glob_gen_storage1: 00000000    pers_glob_gen_storage2: 00000000
  pers_glob_gen_storage3: 00000000    pers_glob_gen_storage4: 00000000
  pers_glob_gen_storage5: 00000000    pers_glob_gen_storage6: 00000000
  pers_glob_gen_storage7: 00000000                 ddr_cntrl:       00
               pwr_state: 00ff008f             aux_pwr_state: 000f0080
           ram_ret_cntrl: 00000000         pwr_supply_status: 00000007
        req_pwrup_status: 00000000        req_pwrup_int_mask: 00fff4bf
        req_pwrup_int_en                   req_pwrup_int_dis
          req_pwrup_trig                   req_pwrdwn_status: 00000000
     req_pwrdwn_int_mask: 00fff4bf         req_pwrdwn_int_en
      req_pwrdwn_int_dis                     req_pwrdwn_trig
          req_iso_status: 00000000          req_iso_int_mask: 00000017
          req_iso_int_en                     req_iso_int_dis
            req_iso_trig                    req_swrst_status: 00000000
      req_swrst_int_mask: fbf717df          req_swrst_int_en
       req_swrst_int_dis                      req_swrst_trig
            csu_br_error: 00009191           mb_fault_status: 00000000
          error_status_1: 00000000          error_int_mask_1: ffff32ff
          error_int_en_1                     error_int_dis_1
          error_status_2: 01000000          error_int_mask_2: 073f1f3f
          error_int_en_2                     error_int_dis_2
        error_por_mask_1: ffff32ff            error_por_en_1
         error_por_dis_1                    error_por_mask_2: 073f1f3f
          error_por_en_2                     error_por_dis_2
       error_srst_mask_1: ffff32ff           error_srst_en_1
        error_srst_dis_1                   error_srst_mask_2: 073f1f3f
         error_srst_en_2                    error_srst_dis_2
        error_sig_mask_1: 000000c3            error_sig_en_1
         error_sig_dis_1                    error_sig_mask_2: 00001600
          error_sig_en_2                     error_sig_dis_2
              error_en_1: 00000000                error_en_2: 073e0000
               aib_cntrl                          aib_status: 00000000
            global_reset: 00000000     rom_validation_status: 00000003
rom_validation_digest_0: 1b7d32b9   rom_validation_digest_1: e1455513
rom_validation_digest_2: 549e6276   rom_validation_digest_3: 12e0c00e
rom_validation_digest_4: a80ab074   rom_validation_digest_5: 31c67e12
rom_validation_digest_6: eb4f93c2   rom_validation_digest_7: daecec5e
rom_validation_digest_8: 1409d274   rom_validation_digest_9: a7cf9780
rom_validation_digest_10: 952a6364  rom_validation_digest_11: 97aaedc8
             safety_gate: 00000006                 mbist_rst: 00000000
             mbist_pg_en: 00000000               mbist_setup: 00000000
              mbist_done: 00000000                mbist_good: 00000000
              safety_chk: 00000000

xsct% mrd 0xFFD80530
FFD80530:   00000000

xsct% mrd 0xFFD80540
FFD80540:   01000000

>From the register reference 
>(https://docs.xilinx.com/r/en-US/ug1087-zynq-ultrascale-registers/ERROR_STATUS_2-PMU_GLOBAL-Register),
> this last line means that it is a PMU_SERVICE error. Some online forums 
>suggest it could be an issue with power sequencing. But if that's the case, I 
>don't understand why it doesn't occur with the PetaLinux-built BOOT.BIN.

I locally patched meta-xilinx to use the CBR method for PMU FW loading and 
confirmed that PS_ERROR_OUT is not asserted. So for us it is a simple fix, but 
I'd really like to figure out why before just committing the change.

I have a few questions:

  1.  Is there a reason why PetaLinux uses the CBR method, while meta-xilinx 
uses the FSBL method?
  2.  Can anyone explain why we would see the PMU_SERVICE issue when using FSBL 
method, but not CBR method?
  3.  Would layer maintainers accept a patch that adds the CBR method for 
loading PMU FW?

Thanks,
Chris

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5208): 
https://lists.yoctoproject.org/g/meta-xilinx/message/5208
Mute This Topic: https://lists.yoctoproject.org/mt/98128052/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

  • [meta-xilinx] PMU_SERVIC... Chris Laplante via lists.yoctoproject.org
    • Re: [meta-xilinx] P... Mark Hatle
      • Re: [meta-xilin... Chris Laplante via lists.yoctoproject.org
        • Re: [meta-x... Sandeep Gundlupet Raju via lists.yoctoproject.org
          • Re: [me... Chris Laplante via lists.yoctoproject.org
            • Re... Chris Laplante via lists.yoctoproject.org
              • ... Sandeep Gundlupet Raju via lists.yoctoproject.org
                • ... Chris Laplante via lists.yoctoproject.org
                • ... Sandeep Gundlupet Raju via lists.yoctoproject.org
                • ... Chris Laplante via lists.yoctoproject.org

Reply via email to