> On Mar 19, 2015, at 9:24 PM, Tyler Baker <tyler.baker(a)linaro.org> wrote:
>
> FYI, not sure if you are on 96boards dev list
Thanks Tyler!
[I'm not on the mailing list, so will have to reply in a new thread.]
>
> ---------- Forwarded message ----------
> From: Jerome Forissier <jerome.forissier(a)linaro.org>
> Date: 19 March 2015 at 11:18
> Subject: [Dev] HiKey: ARM TF BL1 hangs when compiled with GCC 4.9
> To: dev <dev(a)lists.96boards.org>
>
>
> 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].
>
> Basically I found two separate issues, and I'm not sure if they are bugs in GCC or HiKey ATF. Here is the story...
>
> 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?
Yes, this is exactly correct. Compiler assumes that it is compiling normal application user-level code, and treats references to null address as undefined code, which it is free to optimize as it sees fit. In this case the compiler seems to have decided that value in w1 register is never used because it is live only on the path that leads to write-to-null. Note, that the compiler still kept the write itself to keep parity in thrown exceptions between original and optimized code.
Any code that references null address as a valid memory location should use -fno-delete-null-pointer-checks compiler flag. This flag is often added automatically for toolchains that target bare-metal, and, I'm guessing, you are using a "normal" aarch64-linux-gnu toolchain.
>
> 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.
Let us (Linaro TCWG) know if this doesn't go away with -fno-delete-null-pointer-checks. The best way is to file a bug for GCC product in bugs.linaro.org.
>
> So... What kind of bugs do you guys think we have here, and who should I report them to?
>
> [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)
> [4] https://github.com/96boards/documentation/wiki/UEFI
> [5] https://github.com/96boards/arm-trusted-firmware/blob/bbd623798cb775c4c0445…
> [6] https://github.com/96boards/arm-trusted-firmware/blob/bbd623798cb775c4c0445…
> [7] https://github.com/96boards/arm-trusted-firmware/blob/bbd623798cb775c4c0445…
>
--
Maxim Kuvyrkov
www.linaro.org
On Tue, Mar 17, 2015 at 12:16 PM, Peter Griffin
<peter.griffin(a)linaro.org> wrote:
> For fun I've done a minimal U-Boot port for the HiKey board, I thought I'd
> post it here in case anyone else is interested. This work is based on top of
> Linus Walleij Juno port.
Nice work, as mentioned I think all deps are upstream and you should be
able to just rebase on master and start to submit patches upstream.
It seems the most useful part of my stuff was the ATF docs and my
funky makefiles :)
Yours,
Linus Walleij
Hi,
There's a change pending to enable PSCI on HiKey:
https://github.com/96boards/linux/pull/15
A regression is introduced when using HiSilicon bootloader:
we'll have one core when using Hisilicon's bootloader.
Here's the summary:
* current dtb + hisilicon bootloader: boot images, all cores enabled
* current dtb + uefi: boot images, one core enabled
* psci enabled dtb + hisilicon bootloader: boot images, one core enabled
* psci enabled dtb + uefi: boot images, all cores enabled
It won't be much of an issue since the long term plan is to deprecate HiSilicon
bootloader in favor of UEFI. Unfortunately, UEFI isn't feature complete (SD
card support missing, flash to eMMC limited to 128M, etc...).
In the meantime, moving forward it's proposed to provide a legacy dtb and use
the PSCI enabled combination (UEFI + kernel) as the default as it is the
long term plan. It mitigates the issue for people using HiSilicon bootloader
while it enables people using UEFI.
Another option is to keep the status quo until UEFI is there
(speculation is "in 2 weeks")
and switch the default dtb at that time.
The question is which default dtb should be used? Opinions?
Cheers,
Fathi
Hi,
I have been trying to flash Peter's u-boot port to my early access
hikey board without success. I'm stuck trying to use the burn-boot
tool as the usb-serial device used in download mode keeps
disconnecting.
[ 165.408788] option 3-3:1.0: device disconnected
[ 251.495189] usb 3-3: new full-speed USB device number 6 using xhci_hcd
[ 251.624288] usb 3-3: New USB device found, idVendor=12d1, idProduct=3609
[ 251.624292] usb 3-3: New USB device strings: Mfr=1, Product=4, SerialNumber=0
[ 251.624293] usb 3-3: Product: \xffffffe3\xffffff84\xffffffb0㌲㔴㜶㤸
[ 251.624295] usb 3-3: Manufacturer: 䕇䕎䥎
[ 251.624780] option 3-3:1.0: GSM modem (1-port) converter detected
[ 251.624862] usb 3-3: GSM modem (1-port) converter now attached to ttyUSB0
[ 252.131320] usb 3-3: USB disconnect, device number 6
[ 252.131539] option1 ttyUSB0: GSM modem (1-port) converter now
disconnected from ttyUSB0
[ 252.131560] option 3-3:1.0: device disconnected
What I have tried and has not worked.
* Using various PC's, System76 laptop w/Ubuntu 14.10, Chromebook
Pixel 2 w/Debian 8, and Dell XPS8700 w/Debian 8 headless. All these
system show the kernel messages above.
* Disabling network manager
* sudo echo 12D1 3609 > /sys/bus/usb-serial/drivers/option1/new_id;
sudo mknod /dev/ttyUSB0 c 188 0 as suggested by the wiki
* Using other micro-usb cables.
* Created a script to loop the burn-boot tool
Any thing else to try?
Thanks,
--
Tyler Baker
Tech Lead, LAVA
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
I got tired of switching out the jumper, connecting the micro-USB cable, etc and tried:
root@hikey:~# dd if=/tmp/fip.bin of=/dev/mmcblk0p4
Which works, so if you want to upgrade UEFI you can do it in linux. And with the latest changes by Leo that I just merged into ATF 'reboot' now works as well!
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
Hi everyone,
Could I ask that people report all bugs regarding HiKey here:
https://github.com/96boards/bugs/issues
Also if you are working on an problem reported in a issue, please
update the issue data with the current status when you send a status
update out to the list. It is easier for us to track progress on the
issues there rather than via email. Everything is all in one place
then. This will make Usman and my job a lot easier.
Thanks,
Scott
--
Scott Bambrough
Technical Director, Member Services
Linaro
Hi Folks
I've been looking a simple ways to hack together a simple through hole
mezzanine board.
One way is to get hold of a small protoboard[1] and hook it up to a 2mm
to 2.54mm converter board such as this one by a small outfit called
bitwizard[2].
I've been in touch with bitwizard and they are happy to make a run of
boards with a male connector on the underside of the adapter board so we
can hook it up directly to the 96boards LS connector. After that I just
plan to drop the protoboard on the 2.54mm pins, solder it down and start
creating...
However the postage costs from Holland might be a bit steep for just me
so I wondered if anyone else was interested in a group buy. If you're in
the UK I can post out from here... if you're not in the UK and want in
on the action I guess I could hand over some boards at the next
'connect. Guesstimated numbers are £3 per board plus £1 for P&P.
Daniel.
[1]
http://goo.gl/9hbSVe
[2]
http://www.bitwizard.nl/cat/product_info.php?cPath=35&products_id=139
