On 1 March 2012 00:40, Subodh Nijsure <snijsure(a)grid-net.com> wrote:
> Hello,
>
> (Pardon if this is out-of-scope for linaro-dev mailing list )
>
> Is there anybody trying to get Linaro to run on "cheap" AuraSlate
> (http://www.auraslate.com/) tablet? If you are would be nice to
> collaborate...
I like their website: Mischief encouraged. Hackers welcome.
They should post the hardware schematic on the site or at least some
indication what the SoC is. If its one of our member's SoCs then it
may be interesting.
> This is the only affordable ARM tablet that I have found with bootrom so I
> am trying to figure out how one gets started running Linaro on brand new
> hardware... Any specific page I should look at on https://wiki.linaro.org?
>
> Regards,
> -Subodh Nijsure
>
> (NOT affiliated with AuraSlate in any way)
>
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
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
From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
CMA heap needs to know misc device to be able to do the link between
ION heap and CMA area reserved in board configuration file.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
---
drivers/gpu/ion/ion.c | 20 --------------------
drivers/gpu/ion/ion_priv.h | 22 ++++++++++++++++++++++
2 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/ion/ion.c b/drivers/gpu/ion/ion.c
index 37b23af..dbfdd7e 100644
--- a/drivers/gpu/ion/ion.c
+++ b/drivers/gpu/ion/ion.c
@@ -34,26 +34,6 @@
#define DEBUG
/**
- * struct ion_device - the metadata of the ion device node
- * @dev: the actual misc device
- * @buffers: an rb tree of all the existing buffers
- * @lock: lock protecting the buffers & heaps trees
- * @heaps: list of all the heaps in the system
- * @user_clients: list of all the clients created from userspace
- */
-struct ion_device {
- struct miscdevice dev;
- struct rb_root buffers;
- struct mutex lock;
- struct rb_root heaps;
- long (*custom_ioctl) (struct ion_client *client, unsigned int cmd,
- unsigned long arg);
- struct rb_root user_clients;
- struct rb_root kernel_clients;
- struct dentry *debug_root;
-};
-
-/**
* struct ion_client - a process/hw block local address space
* @ref: for reference counting the client
* @node: node in the tree of all clients
diff --git a/drivers/gpu/ion/ion_priv.h b/drivers/gpu/ion/ion_priv.h
index 3323954..82e44ea 100644
--- a/drivers/gpu/ion/ion_priv.h
+++ b/drivers/gpu/ion/ion_priv.h
@@ -22,6 +22,8 @@
#include <linux/mutex.h>
#include <linux/rbtree.h>
#include <linux/ion.h>
+#include <linux/miscdevice.h>
+#include <linux/rbtree.h>
struct ion_mapping;
@@ -38,6 +40,26 @@ struct ion_kernel_mapping {
struct ion_buffer *ion_handle_buffer(struct ion_handle *handle);
/**
+ * struct ion_device - the metadata of the ion device node
+ * @dev: the actual misc device
+ * @buffers: an rb tree of all the existing buffers
+ * @lock: lock protecting the buffers & heaps trees
+ * @heaps: list of all the heaps in the system
+ * @user_clients: list of all the clients created from userspace
+ */
+struct ion_device {
+ struct miscdevice dev;
+ struct rb_root buffers;
+ struct mutex lock;
+ struct rb_root heaps;
+ long (*custom_ioctl) (struct ion_client *client, unsigned int cmd,
+ unsigned long arg);
+ struct rb_root user_clients;
+ struct rb_root kernel_clients;
+ struct dentry *debug_root;
+};
+
+/**
* struct ion_buffer - metadata for a particular buffer
* @ref: refernce count
* @node: node in the ion_device buffers tree
--
1.7.0.4
Hi Bernhard
I added support for device trees in this commit:
http://review.android.git.linaro.org/#change,1359
Is there any reason iMX6 can't make use of this rather than having a
custom make recipe in tasks/kernel.mk? I believe that iMX6 just needs to
add the following line to its BoardConfig.mk ...
DEVICE_TREES := imx6q-sabrelite:board.dtb
--
Tixy
Hello,
One of the issues with https://android-build.linaro.org/ is that, if
build fails, it's not easy to tell if it happened because of
compilation error ("real" failure) or due to non-deterministic error
with setting up infrastructure for build (e.g. during source checkout).
The latter not so uncommon due to vast source size of Android and
complexity of cloud infrastructure.
This became especially problematic with start of automated CI loop,
where it leads to false negatives when doing pre-merge testing.
Improving this situation was subject of few blueprints in which
Infrastructure team worked, and recently, a solution was deployed. With
it, if a build fails due to non-deterministic infrastructure error, it
will get status of "NOT BUILT", meaning that a build never actually got
to compilation phase. Suggested action in such case is to retry.
Please note that Jenkins there is some inconsistency within the Jenkins
itself regarding NOT BUILT status - "Pending" is used as a display name
in places, and the same gray icon used as for ABORTED builds. So,
please keep that in mind, or yet better use Build Frontend.
Unfortunately, even short weekend testing showed that error separation
achieved is not ideal (folks who participated in Connect Q4.11
session dedicated to this, may remember that I said that it would
take adding AI to do that properly ;-) ).
In particular, if there was an issue with manifest file (essentially,
an error in Android source code), it will be reported as NOT BUILT
instead of FAILED. Here's example of such build:
https://android-build.linaro.org/jenkins/job/linaro-android_panda-ics-gcc44…
Opposite miscategorization may also happen: very early infra error may
be reported as FAILED instead of NOT BUILT. Example:
https://android-build.linaro.org/jenkins/job/linaro-android_panda-ics-gcc46…
So, Infrastructure team will continue to work on improving reliability
of builds, but in the meantime please keep looking in the build logs for
actual cause of the failure (feel free to report unexpected build
status to https://bugs.launchpad.net/linaro-android-infrastructure)
--
Best Regards,
Paul
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