Hi,
I use pre-built version of linaro toolchain (got from http://people.linaro.org/~michaelh/incoming/binaries/) to build a uImage.
The build succeeded, but the uImage couldn't start.
The console hangs at:
Using FEC0 device
TFTP from server 10.193.100.158; our IP address is 10.193.102.233
Filename 'uImage_linaro'.
Load address: 0x70800000
Loading: #################################################################
#################################################################
#################################################################
#######################
done
Bytes transferred = 3193292 (30b9cc hex)
## Booting kernel from Legacy Image at 70800000 ...
Image Name: Linux-2.6.38-01026-gc9c8ead
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3193228 Bytes = 3 MB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Does anyone meet this before?
How can I fix it?
Thanks~~
Yours
Terry
* Started with some day-to-day activities in the team. Looking after the
proposals and the cbuild scheduler. Will start
Created problem log for scheduler problems, there is a link to it from the
jobs page. https://wiki.linaro.org/WorkingGroups/ToolChain/SchedulerProblems
* Worked on producing graphs for benchmark results using matplotlib.
Michael: Would it be ok to put my script in
linaro-toolchain-benchmarks/scripts?
* Kicked off some benchmarks with gcc-linaro-4.6-2012.01. To start with
coremark, eembc, denbench, pybench and spec2000. We will see what's there
after the weekend.
Variants: os-neon, o2-neon, o3-neon-novect and o3-neon.
/Regards
Åsa
== GDB ==
* Implemented, tested, and posted for discussion yet another version
of remote support for "info proc" and core file generation, this
time via accessing /proc files via generic file I/O primitives.
== GCC ==
* Tested and merged Revital's fix for LP #879725.
* Tested Richard's patch to help code generation for NEON strided
loads by enabled forward-propagation of subreg expressions. This
caused optimization failures on x86_64; investigated the root
cause and engaged in discussion on mailing list on potential fixes.
* Helped Ramana look into PR 43808 and PR 50313.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Continued work on 64-bit shifts. I've tidied up most of the nastiness I
had in my first attempt at this work, unified the logic into fewer
places, and fixed the one logic error that I knew about. I had a
mysterious reload bug that just wouldn't go away, but having stared at
it for some time I've decided that what I was doing wasn't the best
option in any case, and the new way seems to work. I still have the
problem that register-allocation prefers to allocate the values in
core-registers, even when it would seem to me to work better in NEON.
This maybe because the shift amount must be negated in some cases, and
there isn't a neon instruction for that.
Continued trying to use LAVA to do builds. Unfortunately this seems to
have hit against a lava-test bug. Filed as lp:915915.
Hi,
* built linaro binary toolchain using Michaels crosstool-ng environment:
* disabled multiarch and pkg-config
* uses eglibc 2.13 (due to RPC headers)
* using Linux kernel version 2.6.32.48 (longterm)
* debugged why /sbin/init fails when using the linaro binary toolchain:
* the loader and libc of the binary toolchain is build for armv7
* the binaries (init, busybox, ...) are linked against this glibc and
using the libdl-2.13.so of the binary toolchain
* it causes the boot to fails due to illegal insn caused by the dl
* built the minimal image for armv7-a:
* use the vexpress_defconfig of linaro 3.1 tree linux-linaro-3.1.git
(instead of the OE vesatilebp kernel)
* boots fine using the vexpress-a9 QEMU system model
* sato image (X and gtk+ apps) for armv7-a:
* Tremor (vorbis): inline assembly only supports ARM mode
quick workaround: undefine _ARM_ASSEM_ to fall back to C
* pulseaudio/libatomics-ops: inline asm that only supports ARM mode
quick workaround: use the latest version from upstream
* gtk+_2.24.8 fails due to the libstdc++ libtool archive
easy fix: delete the *la files (just like most of the distributors)
the *la files prevent the the binary toolchain from being "relocatable"
* sato image boots and shows the gui but the X resolution is higher and
the X cursor behaves strange (probably not a miscompile but a
difference of the linaro kernel)
Regards,
Ken
RAG:
Red:
Amber:
Green: good progress on A15 vexpress system model
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-02-20 || ||
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| ||
(for blueprint definitions: https://wiki.linaro.org/PeterMaydell/QemuKVM)
Historical Milestones:
||a15-usermode-support || 2011-11-10 || 2011-11-10 || 2011-10-27 ||
||upstream-omap3-cleanup || 2011-11-10 || 2011-12-15 || 2011-12-12 ||
== cp15-rework ==
* estimate shifted back since it turns out we can do something useful
in initial-a15-system-model without this as a prerequisite, so that's
a better order to do things in
== initial-a15-system-model ==
* I now have a working vexpress-a15 board model, and enough of the a15
private peripheral region and CPU definition that we can boot a
kernel compiled for A15-without-LPAE
* patchseries mostly looks ok to upstream but there are some loose ends
to fix up involving SMP secondary boot CPU protocol and making sure
the right one of the two graphics controllers gets to display things;
also it depends on some patches in the Calxeda/Samsung patchseries
== other ==
* patch review: Calxeda now basically ready to commit, another round
with Samsung
* made qemu-linaro 2012.01 release
* usual round of meetings etc
==Progress===
* Backported one part of the partial-partial PRE patch . Still looking into it.
* Investigate PR48308 - a bug where combine was generating incorrect
transformations.
* Reopened PR50313 - a bug which I originally thought was a dup of PR48308.
* Looked at upstream bugzilla for sometime and triaged a few bugs.
* Linaro patch review.
=== Plans ===
* Continue looking at partial-partial PRE and try and understand it further.
* Look at PR50313 further
* Upstream patch review.
* Finish submitting PGO patch and ABI tests patch
* Look at Andrew's patches for neon shifts -
Absences.
* Feb 6-10 : Linaro Connect Q1.12.
* Feb 13- 18 : Holiday.
==Progress===
* Short week - 4 days only after the bank holiday monday.
* Investigated PR48308 for a bit.
* Caught up with emails after vacation.
* Looked at fate an automatic tester for libav to validate my fixed
to fp conversions . Need to finish that off.
* 1 more bug with output_move_double ICE looked at briefly. Appears
to be memory corruption but valgrinding didn't find the issue.
Prioritizing PR48308 above this.
=== Plans ===
* Look at PR48308 a bit more seriously.
* Finish my long standing patches.
Absences.
* Feb 6-10 : Linaro Connect Q1.12.
* Feb 13- 18 : Holiday.
Amber noticed this on her Twitter feed: a L4 microkernel based
para-virtualisation that runs on the A9:
http://l4dev.org/
They're currently running the 11.12 LEB on a Versatile Express. The
project overview:
http://l4dev.org/codezero_overview
talks about their 'hyperswitch' method to reduce the
para-virtualisation overhead and reduce the number of changes to the
Linux kernel.
-- Michael
The GCC release tested up just fine. The branch is now open for commits.
The next release is Thursday the 9th of February. Note that this is
in the middle of Connect.
-- Michael