Hi,

On 19 March 2015 at 20:18, Jerome Forissier <jerome.forissier@linaro.org> wrote:
Hi all,

I am running the ARM Trusted Firmware on my HiKey board. I found that BL1 hangs if I build it with the version of GCC that comes with my Ubuntu 14.10 distribution [1] or with another 4.9 build from Linaro [2]. However, it works as expected if I use the 4.8 Linaro build [3] as recommended on the HiKey UEFI wiki [4].

it isn't a recommendation. Using GCC 4.8 is done on purpose. See the line "export AARCH64_TOOLCHAIN=GCC48".
 
Basically I found two separate issues, and I'm not sure if they are bugs in GCC or HiKey ATF. Here is the story...

it's a known issue. EDKII should be built with GCC 4.8. It's using some compilers profile and GCC 4.9 isn't officially supported at the moment afaik.
 

With GCC 4.9 [1], the boot hangs, LED#2 blinks and "00000000f20003e8" is printed on UART0 about every second. Let's call this bug #1. The hang occurs in hi6220_pll_init() [5], execution never gets passed this line:
    mmio_write_32(0x0, 0xa5a55a5a);

So I checked the objdump outputs (bl1.dump).

- Working compiler [3] gives:
    f98041f0:   d2800000        mov     x0, #0x0                        // #0
    f98041f4:   528b4b41        mov     w1, #0x5a5a                     // #23130
    f98041f8:   72b4b4a1        movk    w1, #0xa5a5, lsl #16
    f98041fc:   b9000001        str     w1, [x0]

- Bad compiler [1] produces:
    f9804184:   d2800000        mov     x0, #0x0                        // #0
    f9804188:   b900001f        str     wzr, [x0]
    f980418c:   d4207d00        brk     #0x3e8

What?! Is there some kind of smart detection in the compiler assuming that one shouldn't write to address zero?

If I change address to 0x4, the code goes past this location but later hangs with the same LED status as above (b0100) and code "0000000096000021" on the console. This is bug #2.

I tracked it down to the initialization of some structures on the stack when entering usb_handle_control_request() [6]. Looks like an alignment issue, since removing the packed attribute on struct usb_endpoint_descriptor [7] fixes the bug.

So... What kind of bugs do you guys think we have here, and who should I report them to?

 Better ask Saul^Leif for the full story and implication.
 

[1] aarch64-linux-gnu-gcc (Ubuntu/Linaro 4.9.1-16ubuntu6) 4.9.1
[2] aarch64-linux-gnu-gcc (Linaro GCC 2014.11) 4.9.3 20141031 (prerelease)
[3] aarch64-linux-gnu-gcc (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro GCC 4.8-2014.04) 4.8.3 20140401 (prerelease)

Thanks,
-- 
Jerome