Boot.bin broken with 2018.1 Vivado release

[zeroday-engineer]

I've built all the necessary boot files and attempted to use mkbootimage with the ZCU104 dev board and found that i get a printout only from the FSBL, and i don't see anything from the ATF or Uboot... But when i run bootgen against the same boot.bif file and binaries, the device boots successfully.

[k-schaefer]

I can confirm this issue. It seems like the PMU firmware version 1.0 is somehow not working properly. Therefore it does not respond to the FSBL as intended. The FSBL runs successfully until stage 4 where some IPI messaging between FSBL and PMU take place.

[anssih]

I believe this is because the code in src/file/elf.c seems to make some assumptions about the layout of the ELF binary, i.e. it seems to just copy all the data as-is until the end of the first encountered NOBITS section.

So in the case of the below PMUFW it would only copy until end of .sdata2. The FSBL stage 4 failures occurs because the .srdata section is missing from the boot image. I think the .bss section should also be included in the image.

$ readelf --sections pmufw.elf
There are 26 section headers, starting at offset 0x2e1e0:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .vectors.reset    PROGBITS        ffdc0000 0000a0 000008 00  AX  0   0  4
  [ 2] .vectors.sw_excep PROGBITS        ffdc0008 0000a8 000008 00  AX  0   0  4
  [ 3] .vectors.interrup PROGBITS        ffdc0010 0000b0 000008 00  AX  0   0  4
  [ 4] .vectors.hw_excep PROGBITS        ffdc0020 0000c0 000008 00  AX  0   0  4
  [ 5] .text             PROGBITS        ffdc0050 0000f0 01007c 00 WAX  0   0 16
  [ 6] .rodata           PROGBITS        ffdd00cc 01016c 003c74 00   A  0   0  4
  [ 7] .data             PROGBITS        ffdd3d40 013de0 003730 00  WA  0   0  4
  [ 8] .sdata2           NOBITS          ffdd7470 017510 000000 00  WA  0   0  1
  [ 9] .sdata            PROGBITS        ffdd7470 0185f4 000000 00   W  0   0  1
  [10] .sbss             PROGBITS        ffdd7470 0185f4 000000 00   W  0   0  1
  [11] .bss              NOBITS          ffdd7480 017510 004564 00  WA  0   0 32
  [12] .srdata           PROGBITS        ffddb9e4 017510 000ce4 00  WA  0   0  4
  [13] .stack            NOBITS          ffddc6c8 0181f4 001000 00  WA  0   0  1
  [14] .xpbr_serv_ext_tb PROGBITS        ffddf6e0 0181f4 000400 00  WA  0   0  4
  [15] .debug_line       PROGBITS        00000000 0185f4 00263b 00      0   0  1
  [16] .debug_info       PROGBITS        00000000 01ac2f 007951 00      0   0  1
  [17] .debug_abbrev     PROGBITS        00000000 022580 00103e 00      0   0  1
  [18] .debug_aranges    PROGBITS        00000000 0235c0 000250 00      0   0  8
  [19] .debug_frame      PROGBITS        00000000 023810 00019c 00      0   0  4
  [20] .debug_loc        PROGBITS        00000000 0239ac 000383 00      0   0  1
  [21] .debug_str        PROGBITS        00000000 023d2f 001555 01  MS  0   0  1
  [22] .debug_ranges     PROGBITS        00000000 025284 000048 00      0   0  1
  [23] .symtab           SYMTAB          00000000 0252cc 004950 10     24 798  4
  [24] .strtab           STRTAB          00000000 029c1c 0044a4 00      0   0  1
  [25] .shstrtab         STRTAB          00000000 02e0c0 00011f 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  p (processor specific)

[tmichalak]

Thanks @anssih for your hint. We have scheduled to get this fixed soon and will definitely start out with verifying your suggestion.

[anssih]

I guess the SHT_NOBITS / SHF_ALLOC check in elf.c is correct (we do not need/want sections that are (sh_type == SHT_NOBITS || !(sh_flags & SHF_ALLOC))), but it shouldn't stop on the first non-matching section. And it also should not assume that the offset between the load address and the ELF offset is the same for each section.

And two corrections to my earlier comment:

• no need to copy .bss. There is no data to copy and the memory area is zero-initialized by the loaded program itself at startup.
• the current code copies until the start of first non-matching section, not until the end like I said.

[tgorochowik]

Fixed by #7, closing.