If you read the guide, especially the hardware pack section, you should get
an idea of what to do. You need to grab the headless image from
snapshots.linaro.org and combine it with the imx hardware pack from
jameswestby.net to produce an image for your board. The instructions on how
to do this are
On Wed, Oct 06, 2010, Alexander Sack wrote:
How about something like
lp:~asac/linaro-image-tools/part-offset-for-non-fs-data-layout instead
of backing out?
Thanks; I think that would work; you might want to patch
root=/dev/mmcblk0p2 too
Perhaps you could add a comment near MMCOFFSET
On Wed, Oct 6, 2010 at 12:58 PM, Loïc Minier loic.min...@linaro.org wrote:
On Wed, Oct 06, 2010, Alexander Sack wrote:
How about something like
lp:~asac/linaro-image-tools/part-offset-for-non-fs-data-layout instead
of backing out?
Thanks; I think that would work; you might want to patch
On Wed, Oct 6, 2010 at 2:28 PM, Loïc Minier loic.min...@linaro.org wrote:
On Wed, Oct 06, 2010, Alexander Sack wrote:
Here what would happen if we use UUID everywhere:
lp:~asac/linaro-image-tools/unify-omap-bootcmd
I've just noticed that this should use $INITRD_ADDR as done in bootm
(not
Hello,
Here are the minutes from today's LandingTeam meeting:
https://wiki.linaro.org/LandingTeams/Meetings/2010-10-06
--Matt
=== Attendees ===
* Torez Smith
* Matt Waddel
* Scott Bambrough
* Loïc Minier
* Anmar Oueja
=== Agenda ===
* Action items from last meeting.
* Achievements /
On Tue, Oct 05, 2010, Tom Gall wrote:
As a side project I've created a fairly simple performance improvement
for the linaro-media-create tool. Basically the copying of the root_fs
happens earlier in the process such that hwpack and a number of other
steps are done in parallel and then at the
I still disagree, but it's not important. IMHO most of the uses of
__raw_readl should be converted to readl or readl_relaxed if you are
worried about efficiency.
The main difference between __raw_readl and readl_relaxed is that the
endianess is well-defined on readl_relaxed.
Arnd
Hi All,
Purpose of this email is to debate on the pros and cons of having a common
ARM context save/restore code.
Currently each SOC has its own way of saving/restoring ARM registers and
there has been a proposal to have a common code for the same instead of
duplicating the same in different
From: Yong Shen yong.s...@linaro.org
it is tested on babbage 3.0
Signed-off-by: Yong Shen yong.s...@linaro.org
---
arch/arm/Kconfig |6 +
arch/arm/mach-mx5/Kconfig |1 +
arch/arm/mach-mx5/Makefile |2 +-
