[QUERY] efibootguard built by GCC 6.2

[chomb...@gmail.com]

Hello,

I tried to use efibootguard on the Siemens IOT2020 but using Mentor Embedded Linux (instead of Yocto).
I used the meta-efibootguard layer that Andreas kindly posted last week.

efibootguard was built and shows its prompt but it is then unable to find a supported watchdog device
(see below for a boot log)

I eventually traced this problem to be a difference in the compiler output.
The init() function of the driver is expected to be registered in the .init_array section

This is definitely the case with GCC 6.3
It unfortunately isn't with GCC 6.2.

I checked this by compiling a single line compilation unit:
void __attribute__ ((constructor)) test (void) {}

readelf shows an .init_array with 6.3 but I get a .ctors section with 6.2

Jan advised me to check here as Andreas may have some hints for me ;)

TIA,
Cedric

[Jan Kiszka]

Thanks for analysing. Interestingly, I can reproduce with gcc 4.8.5 of
my distro. Neither is init_array empty nor is there a ctors section. Is
there some switch that controls this?

>
> Jan advised me to check here as Andreas may have some hints for me ;)

There was also a second issue, and that's where the hints were primarily
targeting.

Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

[Cedric Hombourger]

There was indeed a second issue but wanted to perform a clean build before voicing it :)

The first wic image produced by bitbake appeared to have the 1st partition empty: the efibootguard binary was not there. I wanted to do a clean build because our BSP layer was initialing setting EFI_PROVIDER conditionally:

EFI_PROVIDER ?= "efibootguard"

I then noticed that systemd-boot was compiled. I then changed the assignment to:

EFI_PROVIDER = "efibootguard"

I don't think that's going to make a difference in the output but felt that I should check first

Cedric

[Jan Kiszka]

On 2017-09-05 15:46, Jan Kiszka wrote:
> On 2017-09-05 15:31, chomb...@gmail.com wrote:
>> Hello,
>>
>> I tried to use efibootguard on the Siemens IOT2020 but using Mentor
>> Embedded Linux (instead of Yocto).
>> I used the meta-efibootguard layer that Andreas kindly posted last week.
>>
>> efibootguard was built and shows its prompt but it is then unable to
>> find a supported watchdog device
>> (see below for a boot log)
>>
>> I eventually traced this problem to be a difference in the compiler output.
>> The init() function of the driver is expected to be registered in the
>> .init_array section
>>
>> This is definitely the case with GCC 6.3
>> It unfortunately isn't with GCC 6.2.
>>
>> I checked this by compiling a single line compilation unit:
>> void __attribute__ ((constructor)) test (void) {}
>>
>> readelf shows an .init_array with 6.3 but I get a .ctors section with 6.2
>
> Thanks for analysing. Interestingly, I can reproduce with gcc 4.8.5 of
> my distro. Neither is init_array empty nor is there a ctors section. Is
> there some switch that controls this?

Actually, morty is using 6.2 as well, and we never saw this issue. Could
it be that MEL-specific gcc patches cause that? Maybe you added
something to stay backward compatible. And maybe that something gives
the compiler user control over which ABI is used so that you only need
to append some switch to the recipe.

[Cedric Hombourger]

Could very well be - I am checking with our tools team in parallel. They seem to be suggesting that the sourcery toolchain is indeed configured to use ctors/dtors instead init/fini

[Cedric Hombourger]

Just to update everyone here - I have worked around our compiler issue using a linker script

The 2nd issue (efibootguard binary missing from the 1st partition): it must have been a local issue. The binary was found present after running a clean build.

On Tuesday, September 5, 2017 at 4:36:37 PM UTC+2, Cedric Hombourger wrote:

Could very well be - I am checking with our tools team in parallel. They seem to be suggesting that the sourcery toolchain is indeed configured to use ctors/dtors instead init/fini

On 5 September 2017 at 16:14, Jan Kiszka <jan.k...@siemens.com> wrote:

On 2017-09-05 15:46, Jan Kiszka wrote:

[Claudius Heine]

Hi Cedric,

On 09/06/2017 11:41 AM, Cedric Hombourger wrote:
> The 2nd issue (efibootguard binary missing from the 1st partition): it must
> have been a local issue. The binary was found present after running a clean
> build.

It would be helpful to see the wks file you used for this image.

Cheers,
Claudius

--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de

[Cedric Hombourger]

Hi Claudius,

Sure thing - it is loosely based on the wks excerpt from the documentation:

# short-description: Create an IOT2000 disk image with efibootguard
# long-description: Creates a partitioned EFI disk image for the SIMATIC IOT2000
# using efibootguard, that the user can directly dd to boot media.

# EFI partition containing efibootguard
part --source efibootguard-efi --size 32 --extra-space 0 --overhead-factor 1 --ondisk mmcblk0 --label efi --part-type=EF00 --align 1024

# Two root partitions for updateability, leave away 2nd if not used
part / --source rootfs --size 1024 --extra-space 0 --overhead-factor 1 --ondisk mmcblk0 --fstype=ext4 --label platform0 --align 1024
part --source rootfs --size 1024 --extra-space 0 --overhead-factor 1 --ondisk mmcblk0 --fstype=ext4 --label plaftorm1 --align 1024

# Two config partitions to load boot configuration and kernel
part --source efibootguard-boot --size 32 --extra-space 0 --overhead-factor 1 --ondisk mmcblk0 --label boot0 --align 1024 --part-type=0700 --sourceparams "watchdog=60,revision=2"
part --source efibootguard-boot --size 32 --extra-space 0 --overhead-factor 1 --ondisk mmcblk0 --label boot1 --align 1024 --part-type=0700 --sourceparams "watchdog=60,revision=1"

# Other partitions
part --size 1024 --extra-space 0 --overhead-factor 1 --ondisk mmcblk0 --label persistent --align 1024 --fstype=ext4
part swap --ondisk mmcblk0 --size 512 --fstype=swap --label swap --align 1024

# Important for type of partition table
bootloader --ptable gpt --append="console=ttyS1,115200n8 reboot=efi,warm rw debugshell=5 rootwait initrd=acpi-upgrades-iot2000.cpio"