Add the below two notifier events so drivers which are interested in
knowing the clock status can act accordingly. This is extremely useful
in some of the DVFS (Dynamic Voltage Frequency Scaling) design.
CLK_PREPARED
CLK_UNPREPARED
Signed-off-by: Bill Huang <bilhuang(a)nvidia.com>
---
drivers/clk/clk.c | 75 ++++++++++++++++++++++++++-------------------------
include/linux/clk.h | 2 ++
2 files changed, 41 insertions(+), 36 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index ed87b24..d78ed16 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -516,6 +516,42 @@ struct clk *__clk_lookup(const char *name)
/*** clk api ***/
+/**
+ * __clk_notify - call clk notifier chain
+ * @clk: struct clk * that is changing rate
+ * @msg: clk notifier type (see include/linux/clk.h)
+ * @old_rate: old clk rate
+ * @new_rate: new clk rate
+ *
+ * Triggers a notifier call chain on the clk rate-change notification
+ * for 'clk'. Passes a pointer to the struct clk and the previous
+ * and current rates to the notifier callback. Intended to be called by
+ * internal clock code only. Returns NOTIFY_DONE from the last driver
+ * called if all went well, or NOTIFY_STOP or NOTIFY_BAD immediately if
+ * a driver returns that.
+ */
+static int __clk_notify(struct clk *clk, unsigned long msg,
+ unsigned long old_rate, unsigned long new_rate)
+{
+ struct clk_notifier *cn;
+ struct clk_notifier_data cnd;
+ int ret = NOTIFY_DONE;
+
+ cnd.clk = clk;
+ cnd.old_rate = old_rate;
+ cnd.new_rate = new_rate;
+
+ list_for_each_entry(cn, &clk_notifier_list, node) {
+ if (cn->clk == clk) {
+ ret = srcu_notifier_call_chain(&cn->notifier_head, msg,
+ &cnd);
+ break;
+ }
+ }
+
+ return ret;
+}
+
void __clk_unprepare(struct clk *clk)
{
if (!clk)
@@ -550,6 +586,7 @@ void clk_unprepare(struct clk *clk)
{
mutex_lock(&prepare_lock);
__clk_unprepare(clk);
+ __clk_notify(clk, CLK_UNPREPARED, clk->rate, clk->rate);
mutex_unlock(&prepare_lock);
}
EXPORT_SYMBOL_GPL(clk_unprepare);
@@ -598,6 +635,8 @@ int clk_prepare(struct clk *clk)
mutex_lock(&prepare_lock);
ret = __clk_prepare(clk);
+ if (!ret)
+ __clk_notify(clk, CLK_PREPARED, clk->rate, clk->rate);
mutex_unlock(&prepare_lock);
return ret;
@@ -749,42 +788,6 @@ long clk_round_rate(struct clk *clk, unsigned long rate)
EXPORT_SYMBOL_GPL(clk_round_rate);
/**
- * __clk_notify - call clk notifier chain
- * @clk: struct clk * that is changing rate
- * @msg: clk notifier type (see include/linux/clk.h)
- * @old_rate: old clk rate
- * @new_rate: new clk rate
- *
- * Triggers a notifier call chain on the clk rate-change notification
- * for 'clk'. Passes a pointer to the struct clk and the previous
- * and current rates to the notifier callback. Intended to be called by
- * internal clock code only. Returns NOTIFY_DONE from the last driver
- * called if all went well, or NOTIFY_STOP or NOTIFY_BAD immediately if
- * a driver returns that.
- */
-static int __clk_notify(struct clk *clk, unsigned long msg,
- unsigned long old_rate, unsigned long new_rate)
-{
- struct clk_notifier *cn;
- struct clk_notifier_data cnd;
- int ret = NOTIFY_DONE;
-
- cnd.clk = clk;
- cnd.old_rate = old_rate;
- cnd.new_rate = new_rate;
-
- list_for_each_entry(cn, &clk_notifier_list, node) {
- if (cn->clk == clk) {
- ret = srcu_notifier_call_chain(&cn->notifier_head, msg,
- &cnd);
- break;
- }
- }
-
- return ret;
-}
-
-/**
* __clk_recalc_rates
* @clk: first clk in the subtree
* @msg: notification type (see include/linux/clk.h)
diff --git a/include/linux/clk.h b/include/linux/clk.h
index b3ac22d..16c1d92 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -43,6 +43,8 @@ struct clk;
#define PRE_RATE_CHANGE BIT(0)
#define POST_RATE_CHANGE BIT(1)
#define ABORT_RATE_CHANGE BIT(2)
+#define CLK_PREPARED BIT(3)
+#define CLK_UNPREPARED BIT(4)
/**
* struct clk_notifier - associate a clk with a notifier
--
1.7.9.5
CCing the list as well.
---------- Forwarded message ----------
From: Tom Gall <tom.gall(a)linaro.org>
Date: Wed, Mar 13, 2013 at 10:35 AM
Subject: Re: tjbench for libjpeg-8c
To: Anand Kumar <bala.anand.k(a)gmail.com>
Hi Anand,
I had to build tjbench from other sources in order to use it with
libjpeg8c. It's a pretty straight forward recompile. It's been awhile
since I had worked on this. I seem to remember I used the
libjpeg-turbo tjbench source code.
I'll be working on this again quite quite soon as I need to refresh
and push things upstream.
On Wed, Mar 13, 2013 at 8:10 AM, Anand Kumar <bala.anand.k(a)gmail.com> wrote:
> With respect to investigation report on Libjpeg-turbo vs Libjpeg8c, i have a
> query on Libjpeg8c's tjbench.
> https://wiki.linaro.org/TomGall/LibJpeg8.
>
> When i downloaded libjpeg8c source code from the community, i couldn't find
> the tjbench support in libjpeg8c package. But in the above mentioned link i
> could see the benchmark results of tjbench for Libjpeg8c.
>
> Please let me know, where i can get the libjpeg8c package with tjbench
> support.
>
> ~ Ananda
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
--
Regards,
Tom
"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Tech Lead, Graphics Working Group | Linaro.org │ Open source software
for ARM SoCs
w) tom.gall att linaro.org
h) tom_gall att mac.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello
Today I made several changes to OpenEmbedded layers hosted on
git.linaro.org:
- - meta-aarch64
- - meta-linaro
Meta-aarch64 is now empty and is obsolete. Probably will be removed from
server in about month or two.
Meta-linaro repository got new structure based on meta-openembedded one
and contains three layers:
- - meta-aarch64
- - meta-linaro
- - meta-linaro-toolchain
Today meta-aarch64 is just a copy of old one but everything not related
to ARMv8 will be moved from it to meta-linaro.
Meta-linaro-toolchain contains just gcc-linaro and support for external
Linaro cross toolchains (armv7a and armv8 ones).
I considered creation of meta-aarch64-arm-toolchain one with ARM Ltd.
version of gcc but it is not often used option so can stay where it is
now (meta-aarch64).
Instructions how to start building for ARMv8 (with OE) are in wiki:
https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded
Note that any scripts present in 'meta-aarch64' got dropped. If you want
easy way then use 'jenkins-setup' scripts like it is described in wiki.
They are written to be as easy to use as possible.
If you have any problems/questions: reply to this email.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJRQJERAAoJECbKqQEReiUeKFgQAMUYDB1ymQs8ZspWVynJVJMQ
InFsFQUd/QZCgNB9GcG6IepzmViHeMlIxNQ7u+KFABGV8uAz8gwdgcPtWwa/dc1b
wu8u84mmwy77WBIMuX087AiXdg8WhJDJz5sztBoK2PL8Ljn1TFB/R17Ew90eN3zn
o1DpPnbgMGs67phNiTy8GiQxyaaLZub0ZZZ5v00tWdt7x4vazw6n2r8/o+wzGLj2
536KI13Sepso2dg2mrpqzrwVH8KFP7S/rRiDdKI4Gw9FlTPiaiEEadX7OPKx8YC5
j1WIR0u66LCSe+F3NsfNfEgTOXPGVUNgqvemwGYXQuOLUKz7nnnkEdVRUegSuEVj
+bZsgzFunghOsvEgX4ynxLVXgOrkiH4PPMhD+OWcB1pso9+ZdVFTVO2oGOnDg9pK
ov7lidEoUDDIZqHxjy5cV36jDnXt8BTI9uEIjVo9gH/0g/67QImXHVONcppg2MfM
GDfhYorkah3VTo9zgHZKCDEIstT1OsCSg+PNeKCAN6fDUdmnzGxCJNEj2CaRAzaI
vJekxAK0+ptscJ9c+bUmAtcBK+XRvJ9K3naN+apUm13Y6INwKuS68knWzOJc0xhd
rpPQ2EcYd8FP1gspjNJPyQKWr2pAUGQkOGkhHrsrb4nj6mkMDDgZ2ET1x8uxI056
vMRn7PKF7x3bItUP9NzA
=GNf7
-----END PGP SIGNATURE-----
With respect to investigation report on Libjpeg-turbo vs Libjpeg8c, i have
a query on Libjpeg8c's tjbench.
https://wiki.linaro.org/TomGall/LibJpeg8.
When i downloaded libjpeg8c source code from the community, i couldn't find
the tjbench support in libjpeg8c package. But in the above mentioned link i
could see the benchmark results of tjbench for Libjpeg8c.
Please let me know, where i can get the libjpeg8c package with tjbench
support.
~ Ananda
Hello
You are receiving this email because you are subscribed to one or more
mailing lists provided by the lists.linaro.org server.
IT Services are announcing planned maintenance for this server scheduled
for *Friday 15th March 2013, starting at 2pm GMT*. The purpose of the work
is to move the service to another server. There will be some disruption
during this maintenance.
In order to ensure that you do not accidentally try to use the service
while it is being moved, the current server will be shut down at 2pm.
A further email will be sent on Friday afternoon to confirm that the
migration of the service is completed. However, due to the way servers are
found, it may take a while before your computer is able to connect to the
relocated service.
After the old server has been shut down, email sent to any of the lists
will be queued, but it is possible that the sending server will still
trying to deliver the email to the old server rather than the new one when
it is started.
It is therefore *strongly* recommended that you do not send any email to an
@lists.linaro.org email address until you can connect to the new service,
which you will be able to test by trying to use a web browser to connect to
http://lists.linaro.org after you receive the email confirming that the
migration has been completed. Since the old service will be shut down, if
you are able to connect, you can be sure you have connected to the new
service.
If by Monday you are still unable to connect to the service or you are not
able to send email to an @lists.linaro.org email address, please send an
email to its(a)linaro.org.
Thank you.
Regards
Philip
IT Services Manager
Linaro
Dear Tom,
With respect to your nice investigation report on Libjpeg-turbo Vs Libjpeg8c, I have a query on Libjpeg8c's tjbench
https://wiki.linaro.org/TomGall/LibJpeg8
When i took the Libjpeg8c source code from the Libjpeg community, I did not find the tjbench support in the libjpeg8c package.
But in your Libjpeg8c's performance report, I have observed that tjbench is used for benchmarking.
So please let me know whether the tjbench support for Libjpeg8c package is released to the community.
Thanks & Regards,
Ananda Kumar B
________________________________
This email is confidential and intended only for the use of the individual or entity named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message. - This mail is sent via Sony Asia Pacific Mail Gateway..
State of the Debian/Ubuntu arm64 port
=====================================
*** Arm64 lives! ***
Executive summary
-----------------
* There is now a bootable (raring) image to download and run
* Everything has been rebuilt against glibc 2.17 so it works
* A bit more work is needed to make the rootfs useable as a native buildd
* Multiarch crossbuilding and the build-profile mechanism is mature enough to cross-build
a port from scratch (this is a big deal IMHO)
* All packages, sources and tools are in a public repo and this work should be reproducible.
* This image is fully multiarched so co-installing armhf for a
64/32 mix should work nicely, as should multiarch crossbuilding to
legacy x86 architectures. :-) (but I haven't tried that yet...)
* Linaro wants 'the distros' to take this work forward from here so people interested in
Debian and Ubuntu on 64-bit arm hardware need to step up and help out.
Bootable images
---------------
A milestone was reached this week: Enough packages were built for arm64 to debootstrap an
image which booted to a prompt! After a bit of fettling (and switching to multistrap) I got
an image with all the packages configured which boots with upstart to a login prompt (I
admit, I did get quite excited about this, as it represents the coming together of nearly 3
years work on multiarch, crossbuilding, bootstrapping, cyclic dependencies and arm64 :-)
The images are available for download: http://wiki.debian.org/Arm64Port#Pre-built_Rootfs
And there are destructions there for making your own.
All these packages were cross-built on raring, untangling cyclic dependencies with build
profiles (see wiki.debian.org/DebianBootstrap for how that works), making this the first
(non x86) self-bootstrapped debian port ever (so far as I know). All (?) previous ports have
been done using something else like OpenEmbedded (armel, armhf), RedHat/HardHat (arm, alpha,
mips), something IBMy (s390) to get an initial linux rootfs on which debian packages are
built.
The new bootstrap process is (almost) just a list of sbuild commands. In practice there are
still a few rough edges around cross- build-dependencies so of the 140 packages needed for
the bootstrap, 9 had to be built manually with 'dpkg-buildpackage -aarm64 -d' (to skip
build-dep checks) instead of 'sbuild --host arm64 <package>'.
The current bootstrap packageset status is here:
http://people.linaro.org/~wookey/buildd/raring-arm64/status-bootstrap.html
There is no armv8 (arm64/aarch64) hardware available yet, so this image can currently only
be run in a model. ARM provide a free-beer prorietary 'Foundation model' so we do have
someting to test with. It's sluggish but perfectly useable. Booting the images takes a
couple of minutes on my fairly average machine.
The images are using the Linaro OE release kernels which seem to work fine for this purpose.
Thanks to Marcin for modified bootloader lines in .axf files.
Image status
------------
I was impressed that things basically 'just worked' on first boot. There is of course plenty
of breakage, I'm sure, and I haven't looked very hard yet, but it's a lot better than I
expected after months of just building stuff and testing nothing. (Things that are poorly:
nano can't parse it's own syntax-coluring files for example, and multiarch perl has the
wrong @INC path compiled in; I'm sure there is more). Consider this alpha-grade until it's
been used a bit more.
Things that are not yet built which would make the images a lot more useful are apt and a
dhcp client. apt needs gnupg needs curl needs nss. The nss cross-build needs fixing to
unbung that. A debian chroot without apt turns out to be disappointing quite quickly :-)
Expect an updated image with more packages very soon.
Multiarch crossbuilding
-----------------------
It's really nice to have building and crossbuilding using exactly the same mechanisms
and tools, with all files having one canonical location, and dependency mechanisms that
are reliable. The more I've used this, the more I've been impressed by it. There is
still work to do to expand the set of cross-buildable stuff, but it's a solid base to
work from.
Getting this port working has been 'interesting' because it's attempting 4 new things all at
once: multiarch (file layouts and dependencies), crossbuilding (tools and packaging support
in a distro that historically was always natively built), arm64 (aarch64) support in
packages that need it, and build-profiles to linearise the build-order.
The arm64 part of this is a relatively small part as the heavy lifting has been done
upstream (gcc, (e)glibc, binutils, kernel, libffi, autotools and a lot of minor fixes in
various packages). Thanks are due to doko (Matthias Klose) for sterling work getting all
that integrated into the debian and ubuntu toolchain packages, and infinity (Adam Conrad)
for merging various eglibc branches. There were also hordes of very boring patches of the
form 'update config.sub and guess before building'.
Most of the work has been in making things cross-build (exactly the same fixes needed for
armel/hf too so I've had plenty of help there from canonical types who want cross-building
for arm to work nicely), and particular thinks to Neil Williams for taking on the perl
cross-build challenge and creating the debian-perl-cross package to manage the
cross-configury, whilst also working with upstream to make the whole thing a bit less 1996.
Multiarchifying has been going on nicely in libraries and -dev packages, but things like
perl and python needed significant work, along with a lot of boring bugs saying 'mark this
package MA: foreign' and 'build-dep on python:any or perl-base:any'. Thanks are due to doko
for the python multiarching and Niko Tyni for the perl multiarchification. Getting all 3
'aspects' of multiarch perl, cross-built perl and arm64 perl config to work at the same time
was quite hard work, and there are still bugs there. Wider usage of multiarched perl would
no doubt sort this out reasonably quickly. I started a wiki page to track the status of
multiarched cross-buildable perl: http://wiki.debian.org/Multiarch/Perl . Help would be
welcome.
The build-profile work is described on the http://wiki.debian.org/DebianBootstrap page.
Progress has been greatly helped by GSOC projects last year, with good work on the tools
(crossbuild-essential packages, build-profile support) from P.J McDermott and an impressive
contribution from Johannes Schauer on dependency analysis tools around libdose, and apt
build-profile support.
All of this apart from multiarch perl, crossbuildable perl and build-profile stuff (and
a few pending patches) is already in raring.
Building stuff yourself
-----------------------
Setting up an arm64 build environment is very simple. Use sbuild-createchroot or mk-sbuild
and point at the bootstrap repo, with a bit of config and some updated tools packages from
the repo (amd64 only supplied). Details are given on
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/arm64bootstrap
Once you've created a tarball chroot builds are simply done with
sbuild -c quantal-amd64-sbuild -d quantal --host=arm64 <package.dsc> or
sbuild -c quantal-amd64-sbuild -d quantal --host=arm64 <package>_<version> (I'd love it
if sbuild got smart enough to work out the version itself when given a distro - Roger
says he's working on it)
To deal with the chore of 'find version, run sbuild, sign result, upload to repo, import to
repo, deal with reprepro bitching if you re-upload the same version of something' for every
package build, I wrote 'dimstrap' which is a simple-minded tool to wrap that up and either do
one-off builds or run through a list. It is part of the xbuilder package here:
https://launchpad.net/~linaro-foundations/+archive/cross-build-tools/ It also includes the
logfile-parsing script ('generate html') which generates the nice status pages:
http://people.linaro.org/~wookey/buildd/raring-arm64/status-bootstrap.html
Image building
--------------
The config and instructions provided (in
http://wiki.debian.org/Arm64Port#Building_your_own_rootfs_image ) is
for multistrap. Debootstrap sort-of produces working images too but
takes a lot longer to unpack/configure, and misses out various vital
packages (like libperl5.14). I'm sure it could be kicked into
submission. In theory multistrap (apt really) should have got all the
arch all packages from the main repo, but in practice it refused to do
that so I had to rebuild them or copy them over anyway (grumble).
Any package that installs replaced conffiles seems to generate invalid
dpkg status entries (ifupdown did this to me). I've not got to the
bottom of that yet. Deleting the offending line gets you an image that
works.
Issues
------
General:
The build-profile patches for dpkg and apt need to be pushed into the distro to make
that feature permanent. A thread on debian-devel is working on that
(http://debian.2.n7.nabble.com/Bootstrappable-Debian-proposal-of-needed-chan…).
The main issue is what syntax to use '<>' or '[]' and how to deal with multiple overlapping
profiles. The patches to debian control cannot go in until at least the syntax is agreed and
the tools will parse them without barfing. Johannes ands I will send an updated spec
soonish.
The missing piece of bootstrapping with regard to build-deps is packages that build-dep on
gcc-4.6 or binutils. When cross-building this should be satisfied by <triplet>-gcc-4.6 or
<triplet>-binutils. Nothing makes that happen currently. A scheme has been mooted but
nothing is implemented yet.
There is debate about whether cross-toolchains should build against multiarch libraries
(libgcc, libstdc++) like everything else, or have their own internal copies. Doko and I
disagree on this matter. That will need to be worked out at some point.
We won't get that much further with fixing cross- object-introspection, which is a
non-trivial job.
Image-related:
The images do essentially work but very little has been tested so far.
Multiarch perl still needs work.
nss needs cross-building in order to get apt cross-built
I've not got networking working yet. Info is here:
https://fedoraproject.org/wiki/Architectures/ARM/AArch64/FoundationModel_Ne…
lack of a dhcp client in the image hasn't helped there.
More info
---------
The canonical arm64 port info page is:
http://wiki.debian.org/Arm64Port
Full arm64 cross-build status (i.e everything that has been tried) is here:
http://people.linaro.org/~wookey/buildd/raring-arm64/status.html
All the patches generated so far are here:
http://people.debian.org/~wookey/bootstrap/patches/
(most that can, have been filed as bugs - there is a backlog of stuff
filed in Launchpad but not yet forwarded to the Debian BTS - yes I am
a bad boy - blame the fact that you can't use reportbug or bts from
inside ARM due to their idiotic email policies).
Future work
-----------
Firstly we should say thank you to Linaro for sponsoring this work in various ways over
the last 3 years. We wouldn't be at this point now if it wasn't for that. However
Linaro has a lot of things to do and is trying hard not to do distro's work for them,
concentrating on upstream things. This makes sense for commercially-backed distros like
Red Hat and Ubuntu, but rather less for Debian where we _are_ the distro just as much
as anyone else is, and ultimately someone has to spend the time to get stuff working.
Anyway, I was supposed to stop work on this some time back, but have largely failed to
do so (cross-building is so moreish - there is always one more build to try before
bedtime!) and appreciate being given enough slack to get this to a point of actual
utility. However I expect to have much less time to spend on this from now on, except
insofar as it still co-oncides with things Linaro wants doing. I'd love to hear from
people who actually want to use this, to get more packages built, the Debian
cross-toolchains sorted, build-profiles finalised, and a whole pile of stuff fixed once
Wheezy is released. I'm pretty sure there are quite a lot of people who want multiarch
Debian or Ubuntu on their arm64 machines (or models).
I hear rumours that actual hardware may appear sometime around the middle of the year
with some bagsied for Debian. Setting up the ports infrastructure for that would be
good. I don't know if anyone is interested in building slowly on models in the
meantime, or if we should just carry on crossing and see how far we get. This table
shows that 471 packages in raring can be expected to cross-build already:
http://people.canonical.com/~cjwatson/cross/armhf/raring/
Todo:
Fix up multiarch/cross perl
Fix nss
Build missing packages for apt
Build missing packages for build-essential
Build Debian cross-toolchain
Get all this working in unstable as well as raring
Setup buildds
Build all the other packages
Set up automated bootstraping runs (eventually)
Current setup
-------------
Builds have all been run locally using the sbuild/chroot setup described above and on
the Arm64Port page, which should be easy for anyone to reproduce. The main irritation
is keeping up with raring: out of sync libraries are not MA-installable. Logs are
uploaded to people.linaro.org (rsync). The reprepro repo is on people.debian.org
(dupload). This stuff should probably move to ports.debian.org and ports.ubuntu.com,
but neither of those are set up for cross-building so I'm not quite sure how this will
work.
I could go on at great length about the machinery of profiled bootstrap builds, and
interactions between tools, but it's not very exciting, so will resist. Suffice it to
say that whilst it's all pretty slick I'd still like better buildd tools.
Build-profile changes
---------------------
The build-profile patches are not yet upstreamable so are collecting in the repo.
The patch set so far is here: http://people.debian.org/~wookey/bootstrap/patches/profiles/packages/
Other thanks:
Other people who have helped make this happen in various ways but not got a mention above:
Colin Watson, Dmitry Ledkovs, Steve Langasek, Harry Leibel, Thibaut Girka, Roger Leigh,
Marcus Shawcroft, James Morrisey, Jonathan Austin, Steve McIntyre, Peter Pearse, Aurelien
Jarno, and whoever does sysadmin at people.{linaro,debian}.org
I hope I didn't forget anyone, or any important information.
Feedback from anyone attempting to get this working outside my computer is very
welcome. I have almost certainly forgotten to write down some things, and upload
correct versions of some other things.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Hi, All
I want to use the panda-linaro build from here:
https://android-build.linaro.org/builds/~linaro-android-member-ti/panda-lin…
but with the sdcard create by linaro-android-media-create, I can't boot the
panda board.
Anyone has met the same problem?
attached linaro-android-media-create.log is the output of
the linaro-android-media-create
Following is the output of minicom:
Welcome to minicom 2.5
OPTIONS: I18n
Compiled on May 2 2011, 10:05:24.
Port /dev/ttyUSB0
Press CTRL-A Z for help on special keys
U-Boot SPL 2013.01.-rc1 (Mar 12 2013 - 01:42:53)
OMAP4460 ES1.1
OMAP SD/MMC: 0
** Partition 1 not valid on device 0 **
spl: fat register err - -1
### ERROR ### Please RESET the board ###
U-Boot SPL 2013.01.-rc1 (Mar 12 2013 - 01:42:53)
OMAP4460 ES1.1
OMAP SD/MMC: 0
** Partition 1 not valid on device 0 **
spl: fat register err - -1
### ERROR ### Please RESET the board ###
U-Boot SPL 2013.01.-rc1 (Mar 12 2013 - 01:42:53)
OMAP4460 ES1.1
OMAP SD/MMC: 0
** Partition 1 not valid on device 0 **
spl: fat register err - -1
### ERROR ### Please RESET the board ###
U-Boot SPL 2013.01.-rc1 (Mar 12 2013 - 01:42:53)
OMAP4460 ES1.1
OMAP SD/MMC: 0
** Partition 1 not valid on device 0 **
spl: fat register err - -1
### ERROR ### Please RESET the board ###
--
Thanks,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
linaro-validation(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/pipermail/linaro-validation
Hi,
I'm trying to build the OpenEmbedded AArch64 system again, and it looks like
the file:
http://snapshots.linaro.org/openembedded/sources/git2_git.linaro.org.kernel…
linaro-tracking.git.tar.gz
is corrupt. gzip thinks it ends unexpectedly. Shall I file some kind of ticket
for this or is it something that's fixed out-of-line?
Cheers.
Tim.
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.