patches for enabling 'X' on MOP500 hrefp
Hi, Please find attached patches for enabling 'X' using xorg-fbdev and xorg-ste driver on MOP500 hrefp boards. jcrigby,asac,fgu: hwmem-config-2.6.34-1000-ste-ux500.patch is same as hwmem-usbnet-config-2.6.34-1000-ste-ux500.patch. Please contact should you require more information. -Sudip diff -Naurpw linux-2.6.34/drivers/video/fbmem.c linux-2.6.34-fbmem/drivers/video/fbmem.c --- linux-2.6.34/drivers/video/fbmem.c 2010-10-06 21:01:14.574335894 +0530 +++ linux-2.6.34-fbmem/drivers/video/fbmem.c 2010-10-06 21:02:33.786337074 +0530 @@ -1072,6 +1072,10 @@ static long do_fb_ioctl(struct fb_info * ret = copy_to_user(argp, &fix, sizeof(fix)) ? -EFAULT : 0; break; case FBIOPUTCMAP: + #if defined(CONFIG_MACH_U8500_MOP) + ret = EPERM; + break; + #endif if (copy_from_user(&cmap, argp, sizeof(cmap))) return -EFAULT; ret = fb_set_user_cmap(&cmap, info); @@ -1306,6 +1310,10 @@ static long fb_compat_ioctl(struct file case FBIOGETCMAP: case FBIOPUTCMAP: + #if defined(CONFIG_MACH_U8500_MOP) + ret = EPERM; + break; + #endif ret = fb_getput_cmap(info, cmd, arg); break; --- config-2.6.34-1000-ste-ux500 2010-10-06 12:55:26.082120997 +0530 +++ config-2.6.34-1000-ste-ux500-x-changes 2010-10-06 12:55:35.142122365 +0530 @@ -367,10 +367,10 @@ CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_DISPLAY_AB8500_TERTIARY is not set # CONFIG_DISPLAY_AV8100_TERTIARY is not set CONFIG_DISPLAY_GENERIC_DSI_PRIMARY=y -# CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_AUTO_SYNC is not set +CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_AUTO_SYNC=y # CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_VSYNC is not set # CONFIG_DISPLAY_GENERIC_DSI_SECONDARY is not set -# CONFIG_DISPLAY_SUPPORT is not set +CONFIG_DISPLAY_SUPPORT=y # CONFIG_DLM is not set # CONFIG_DMADEVICES is not set CONFIG_DNOTIFY=y @@ -453,7 +453,7 @@ CONFIG_FORCE_MAX_ZONEORDER=12 # CONFIG_FPE_FASTFPE is not set CONFIG_FPE_NWFPE=y # CONFIG_FPE_NWFPE_XP is not set -# CONFIG_FRAMEBUFFER_CONSOLE is not set +CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAME_WARN=1024 CONFIG_FREEZER=y # CONFIG_FSCACHE is not set @@ -568,7 +568,7 @@ CONFIG_HOTPLUG_CPU=y # CONFIG_HTC_I2CPLD is not set # CONFIG_HTC_PASIC3 is not set # CONFIG_HUGETLB_PAGE is not set -# CONFIG_HWMEM is not set +CONFIG_HWMEM=y CONFIG_HWMON=y # CONFIG_HWMON_DEBUG_CHIP is not set # CONFIG_HWMON_VID is not set @@ -795,7 +795,7 @@ CONFIG_MAGIC_SYSRQ=y # CONFIG_MCDE_DISPLAY_AB8500_DENC is not set # CONFIG_MCDE_DISPLAY_AV8100 is not set CONFIG_MCDE_DISPLAY_GENERIC_DSI=y -# CONFIG_MCDE_FB_AVOID_REALLOC is not set +CONFIG_MCDE_FB_AVOID_REALLOC=y # CONFIG_MD is not set # CONFIG_MEDIA_ATTACH is not set CONFIG_MEDIA_SUPPORT=y ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] cpufreq for freescale mx51
From: Yong Shen
it is tested on babbage 3.0
Signed-off-by: Yong Shen
---
arch/arm/Kconfig |6 +
arch/arm/mach-mx5/Kconfig |1 +
arch/arm/mach-mx5/Makefile |2 +-
arch/arm/mach-mx5/board-mx51_babbage.c | 10 ++-
arch/arm/mach-mx5/clock-mx51.c | 54
arch/arm/mach-mx5/cpu.c|2 +
arch/arm/mach-mx5/cpu_wp-mx51.c| 42 ++
arch/arm/mach-mx5/cpu_wp-mx51.h| 14 ++
arch/arm/plat-mxc/Makefile |2 +
arch/arm/plat-mxc/cpufreq.c| 232
arch/arm/plat-mxc/include/mach/mxc.h | 20 +++-
11 files changed, 382 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-mx5/cpu_wp-mx51.c
create mode 100644 arch/arm/mach-mx5/cpu_wp-mx51.h
create mode 100644 arch/arm/plat-mxc/cpufreq.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d203b84..9ea6c37 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1690,6 +1690,12 @@ if ARCH_HAS_CPUFREQ
source "drivers/cpufreq/Kconfig"
+config CPU_FREQ_IMX
+ tristate "CPUfreq driver for i.MX CPUs"
+ depends on ARCH_MXC && CPU_FREQ
+ help
+ This enables the CPUfreq driver for i.MX CPUs.
+
config CPU_FREQ_SA1100
bool
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 0848db5..7a621b4 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -5,6 +5,7 @@ config ARCH_MX51
default y
select MXC_TZIC
select ARCH_MXC_IOMUX_V3
+ select ARCH_HAS_CPUFREQ
comment "MX5 platforms:"
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index 86c66e7..673daba 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -3,7 +3,7 @@
#
# Object file lists.
-obj-y := cpu.o mm.o clock-mx51.o devices.o
+obj-y := cpu.o mm.o clock-mx51.o devices.o cpu_wp-mx51.o
obj-$(CONFIG_MACH_MX51_BABBAGE) += board-mx51_babbage.o
obj-$(CONFIG_MACH_MX51_3DS) += board-mx51_3ds.o
diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c
b/arch/arm/mach-mx5/board-mx51_babbage.c
index 6e384d9..74627d2 100644
--- a/arch/arm/mach-mx5/board-mx51_babbage.c
+++ b/arch/arm/mach-mx5/board-mx51_babbage.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2009-2010 Freescale Semiconductor, Inc. All Rights Reserved.
* Copyright (C) 2009-2010 Amit Kucheria
*
* The code contained herein is licensed under the GNU General Public
@@ -32,6 +32,7 @@
#include
#include "devices.h"
+#include "cpu_wp-mx51.h"
#define BABBAGE_USB_HUB_RESET (0*32 + 7) /* GPIO_1_7 */
#define BABBAGE_USBH1_STP (0*32 + 27) /* GPIO_1_27 */
@@ -279,8 +280,15 @@ static struct sys_timer mxc_timer = {
.init = mx51_babbage_timer_init,
};
+static void __init fixup_mxc_board(struct machine_desc *desc, struct tag *tags,
+ char **cmdline, struct meminfo *mi)
+{
+ get_cpu_wp = mx51_get_cpu_wp;
+}
+
MACHINE_START(MX51_BABBAGE, "Freescale MX51 Babbage Board")
/* Maintainer: Amit Kucheria */
+ .fixup = fixup_mxc_board,
.phys_io = MX51_AIPS1_BASE_ADDR,
.io_pg_offst = ((MX51_AIPS1_BASE_ADDR_VIRT) >> 18) & 0xfffc,
.boot_params = PHYS_OFFSET + 0x100,
diff --git a/arch/arm/mach-mx5/clock-mx51.c b/arch/arm/mach-mx5/clock-mx51.c
index 6af69de..0709a64 100644
--- a/arch/arm/mach-mx5/clock-mx51.c
+++ b/arch/arm/mach-mx5/clock-mx51.c
@@ -28,6 +28,10 @@
static unsigned long external_high_reference, external_low_reference;
static unsigned long oscillator_reference, ckih2_reference;
+static int cpu_wp_nr;
+static int cpu_curr_wp;
+static struct cpu_wp *cpu_wp_tbl;
+
static struct clk osc_clk;
static struct clk pll1_main_clk;
static struct clk pll1_sw_clk;
@@ -39,6 +43,8 @@ static struct clk ahb_clk;
static struct clk ipg_clk;
static struct clk usboh3_clk;
+DEFINE_SPINLOCK(clk_lock);
+
#define MAX_DPLL_WAIT_TRIES1000 /* 1000 * udelay(1) = 1ms */
static int _clk_ccgr_enable(struct clk *clk)
@@ -330,6 +336,37 @@ static int _clk_lp_apm_set_parent(struct clk *clk, struct
clk *parent)
return 0;
}
+/*!
+ * Setup cpu clock based on working point.
+ * @param wp cpu freq working point
+ * @return 0 on success or error code on failure.
+ */
+static int cpu_clk_set_wp(int wp)
+{
+ struct cpu_wp *p;
+ u32 reg;
+ unsigned long flags;
+
+ if (wp == cpu_curr_wp)
+ return 0;
+
+ p = &cpu_wp_tbl[wp];
+
+ /*use post divider to change freq
+*/
+ spin_lock_irqsave(&clk_lock, flags);
+
+ reg = __raw_readl(MXC_CCM_CACRR);
+ reg &= ~MXC_CCM_CACRR_ARM_PODF_MASK;
+ reg |= cpu_wp_tbl[wp].cpu_podf << MXC_CCM_CACRR_ARM_PODF_OFFSET;
+ __raw_writel(reg, MXC_CCM_CACRR);
+
+ spin_unlock_irqrestore(&clk_lock, flags);
+ cpu_curr_wp = wp;
+
+ return 0;
+}
mx51 cpufreq driver
2nd review. Updated according to comments from Sascha and Arnd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Common ARM context save/restore code
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 places. Though it is technically possible to save/restore common ARM registers in a common place, there are some constraints. 1. Each of the SOC would have it's own set of trustzone implementation which means these registers have to be saved/restored in SOC specific code. 2. Some of the ARM registers (Aux ctrl etc) can be different for different SOCs which means they cannot be handled in common code. So it means that, in the middle of common code, there needs to be many platform specific hooks so that right sequence is followed. This will make the code more unredeable and difficult to debug and maintain. Also I am just wondering is there any other ARM SOC apart from OMAP, which saves/restores ARM registers in SW? Atleast I could not find such code in opensource. Regards Vishwa ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq for freescale mx51
> 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 > I agree with you about that. I will keep that in mind and also notice my colleages this in our future development. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq for freescale mx51
Hi Sascha,
Thanks for your thorough comments.
I have already received comments from Arnd before yours arrived. So some of
the commends you two provided are common.
I acknowledge most of your opinions, except for two, I have some
explanations.
> > +*/
> > > + reg = __raw_readl(MXC_CCM_CACRR);
> > > + reg &= ~MXC_CCM_CACRR_ARM_PODF_MASK;
> > > + reg |= cpu_wp_tbl[wp].cpu_podf << MXC_CCM_CACRR_ARM_PODF_OFFSET;
> > > + __raw_writel(reg, MXC_CCM_CACRR);
>
> We have a simple divider here. Why do we need a reference to struct
> cpu_wp then? This code could look much simpler.
>
> (side note: I'm aware that the original Freescale code is also able
> to change the cpu frequency using the pll instead of the divider, but is
> this really necessary?)
>
Using wp_tbl is because that it also contains information like regulator
voltage. Since the regulator driver for imx51 have not been upstreamed, you
don't see any regulator operation here. Also, like you mentioned, there are
two ways to change cpufreq, by post divider or pll change. And post divider
change is a simpler way and also the only way for babbage, since cpu freq
and ddr freq are all root from the same pll on babbage and they will
interfere each other.
> > +static struct cpufreq_frequency_table imx_freq_table[4];
>
> Three frequencies should be enough for everyone, right? This should be
> dynamically allocated like in other cpufreq drivers.
>
Yes, we only support 3 work points, which is for sure. Actually, we only
support 2 points on most mx51 chips. I supposed it is ok to use static array
here.
Thanks again for review. I will send out updated patch again.
Yong
On Wed, Oct 6, 2010 at 5:51 PM, Sascha Hauer wrote:
> On Thu, Sep 30, 2010 at 01:48:17PM +0300, Amit Kucheria wrote:
> > Add'ed linaro-dev and linux-arm-kernel to CC.
> >
> > Thanks Yong, some feeback follows inline.
> >
> > On 10 Sep 29, Yong Shen wrote:
> > > From: Yong Shen
> > >
> > > ---
> > > arch/arm/Kconfig |6 +
> > > arch/arm/mach-mx5/Kconfig |1 +
> > > arch/arm/mach-mx5/board-mx51_babbage.c | 32
> > > arch/arm/mach-mx5/clock-mx51.c | 53 ++
> > > arch/arm/plat-mxc/Makefile |2 +
> > > arch/arm/plat-mxc/cpufreq.c| 282
>
> > > arch/arm/plat-mxc/include/mach/mxc.h | 20 +++
> > > 7 files changed, 396 insertions(+), 0 deletions(-)
> > > create mode 100644 arch/arm/plat-mxc/cpufreq.c
> > >
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index 4db064e..64ebbc0 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -1517,6 +1517,12 @@ if ARCH_HAS_CPUFREQ
> > >
> > > source "drivers/cpufreq/Kconfig"
> > >
> > > +config CPU_FREQ_IMX
> > > + tristate "CPUfreq driver for i.MX CPUs"
> > > + depends on ARCH_MXC && CPU_FREQ
> > > + help
> > > + This enables the CPUfreq driver for i.MX CPUs.
> > > +
> > > config CPU_FREQ_SA1100
> > > bool
> > >
> > > diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> > > index 1576d51..5956fee 100644
> > > --- a/arch/arm/mach-mx5/Kconfig
> > > +++ b/arch/arm/mach-mx5/Kconfig
> > > @@ -5,6 +5,7 @@ config ARCH_MX51
> > > default y
> > > select MXC_TZIC
> > > select ARCH_MXC_IOMUX_V3
> > > + select ARCH_HAS_CPUFREQ
> > >
> > > comment "MX5 platforms:"
> > >
> > > diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c
> b/arch/arm/mach-mx5/board-mx51_babbage.c
> > > index ed885f9..e449e0b 100644
> > > --- a/arch/arm/mach-mx5/board-mx51_babbage.c
> > > +++ b/arch/arm/mach-mx5/board-mx51_babbage.c
> > > @@ -43,6 +43,31 @@
> > > #defineMX51_USB_PLL_DIV_19_2_MHZ 0x01
> > > #defineMX51_USB_PLL_DIV_24_MHZ 0x02
> > >
> > > +struct cpu_wp *(*get_cpu_wp)(int *wp);
>
> This should be moved to a generic place, otherwise it breaks the build
> when multiple boards are selected.
>
> > > +static int num_cpu_wp = 2;
> >
> > use sizeof(array) instead of hard coding this.
> >
> > > +/* working point(wp): 0 - 800MHz; 1 - 166.25MHz; */
> > > +static struct cpu_wp cpu_wp_auto[] = {
> > > + {
> > > + .pll_rate = 8,
> > > + .cpu_rate = 8,
> > > + .pdf = 0,
> > > + .mfi = 8,
> > > + .mfd = 2,
> > > + .mfn = 1,
> > > + .cpu_podf = 0,
> > > + .cpu_voltage = 110,},
> > > + {
> > > + .pll_rate = 8,
> > > + .cpu_rate = 16000,
> > > + .pdf = 4,
> > > + .mfi = 8,
> > > + .mfd = 2,
> > > + .mfn = 1,
> > > + .cpu_podf = 4,
> > > + .cpu_voltage = 85,},
> > > +};
> >
> >
> > This data should be moved out to a separate file (e.g. mx51_ratetable.h)
> > since it will be useful to other boards too.
> >
> > If other boards can have different rate tables (and they can, depending
> on
> > the revision of the silicon), then we can either 'assemble' the correct
> rate
> > table based on a flag field or have explicit separate rate tables for
> each
> > silicon revision.
> >
> > In any case, I suspect that the
Linaro sound support - Beagleboard
Since I personally have not been able to locate this information anywhere, I have created a wiki page to log the testing and experimentation I have been doing with sound. Please ignore if this is duplicate information. Currently info only for Headless and ALIP linaro images, but I plan on adding netbook. Any additional pointers would be greatly appreciated. https://wiki.linaro.org/KurtTaylor/BeagleBoardSound Regards, Kurt Taylor (krtaylor irc) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Thu, Oct 7, 2010 at 12:14 AM, Alexander Sack wrote: >> Note that there's still the mmc 0:1 which means first partition and >> wont work with the other change we're discussing > > Oh. I assumed u-boot does not see our non-fs data partition and our > boot partition is mmc 0:1. But now I see that we use mmc 0:2 for > mx51evk. I guess Shawn checked that this boots? If so we should guess > it from offset accordingly. > Yes, I can only boot with mmc 0:2 on mx51evk, so u-boot should be able to see the non-fs data partition. -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro-media-create speedup
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 end there's one last rsync > to make sure adjusted files, further installed files are correctly > copied. There might be an interesting speedup + bugfix in aligning the rootfs partition on a power of two, e.g. 1 MiB boundary, as the SD/MMC is flash internally, and undergoes erase/write cycles for fs meta-data. I think only OMAP has constraints on the number of heads/sectors, but we could take a factor of that: 63*255 can't really be factored well, but we could use LBA addressing and start in the middle of a cylinder. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
LandingTeam WG - 2010-10-06 meeting minutes
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 / progress reports * OMAP3 * Versatile Express * deploy options for vexpress * New Business === Action Items === * Matt and Scott to discuss state of Vexpress MMC and then discuss issues with ARM * Loic to send a request for linaro-media-create rewrite to the infrastructure team. * Torez, IGEP display fix needs to be tested on a beagle-board (make sure there are no regression failures) * Torez to test powervr fixes on IGEP and Beagle - if they work they can be added to the hardware packs * Matt to contact ARM about ARM boot monitor deploy questions === Action Items from Previous Meeting === * Torez * Bad LCD on IGEPv2 - Patch posted - will investigate and try soon lp: 607250 * Tested patches - they fix the problem - waiting for patches to work through system * Matt * try to install busybox file system and see if that helps get to shell prompt faster * This filesystem doesn't actually exist yet, but initramfs is probably enough for this test * However a busybox only rootfs could be used as a test image during initial board bring-up * Check with Steve Langasek to see if this is on the radar. The headless is < 100M * Specs for flash support maybe in the next cycle * Try to point to /bin/sh instead of init * didn't help * Try install root FS onto USB stack instead of mmc. See if any of those help with speed of boot. * This helps === Minutes === * Vexpress - * bug LP: 632798 - MMC slowness bug * Try loading a file from the ARM boot monitor to see how long it takes to load from MMC versus flash * Add feature of linaro-media-create to deploy to USB for vexpress * Proposed that linaro-media-create be re-written in the infrastructure team * USB creator may be used as a deploy mechanism * Loic to send a request for this work to be done * OMAP3 * IGEP display fix needs to be tested on the beagle-board to make sure it doesn't break * Hardware pack installation for omap3 tested and works - needs lucid (not karmic) * IGEP wifi setup will be better once the display patch is installed * no other action required - no other instructions will be included * STX drivers * Torez worked with Nicolas Deshcne to get access to the binary drivers and kernel modules * Ricardo Salveti did some of this work for OMAP3 * Test on IGEP and Beagle - if they work they can be added to the hardware packs * Start keeping record of Vexpress issues in a wiki ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On 6 October 2010 17:14, Alexander Sack wrote: > On Wed, Oct 6, 2010 at 2:28 PM, Loïc Minier wrote: >> On Wed, Oct 06, 2010, Alexander Sack wrote: >>> I guess someone (mattman?) should sign this off and see if everything >>> is still fine in qemu. >> >> It's more Peter looking after QEMU these days; Cc:ing him > > Peter, the basic idea is to use linaro-media-create from the branch > mentioned above with --image_file option to produce a bootable qemu > image. beagle board hwpack with headless working for our qemu in > linaro is the goal here. I'm on holiday so I'm not really in a position to test things until the start of next week, I'm afraid. (Also I've had reports that images weren't booting on qemu any more as a result of the kernel triggering an issue with the NAND modelling: https://bugs.launchpad.net/qemu-maemo/+bug/645311 so even if you do test with your updated script it might fail through no fault of the image creation script...) -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 6, 2010 at 2:28 PM, Loïc Minier 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 your doing but mine) > > Note that there's still the mmc 0:1 which means first partition and > wont work with the other change we're discussing Oh. I assumed u-boot does not see our non-fs data partition and our boot partition is mmc 0:1. But now I see that we use mmc 0:2 for mx51evk. I guess Shawn checked that this boots? If so we should guess it from offset accordingly. > >> I guess someone (mattman?) should sign this off and see if everything >> is still fine in qemu. > > It's more Peter looking after QEMU these days; Cc:ing him Peter, the basic idea is to use linaro-media-create from the branch mentioned above with --image_file option to produce a bootable qemu image. beagle board hwpack with headless working for our qemu in linaro is the goal here. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro-media-create speedup
On Wed, Oct 6, 2010 at 10:11 AM, Alexander Sack wrote: > On Wed, Oct 6, 2010 at 4:43 PM, Tom Gall wrote: >> I haven't tested without hwpacks. I'm not sure that's a valid test >> anymore with the removal of flavors and so on from the builds. Outside >> of using an old linaro image, is it valid anymore to call >> linaro-media-create without passing hwpacks? > > I think its still useful in general to have this feature in l-m-c; > someone might run their own builds with kernel included for > convenience. But you are right. as discussed in UP meeting we should > at least spit out a warning or even do a fast-fail check if there is a > kernel in /boot/. Ok. I'll test that variation, adjust the rsync call and unless something else comes up submit a merge proposal. Regards, Tom ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro-media-create speedup
Hi asac,
On Wed, Oct 6, 2010 at 2:43 AM, Alexander Sack wrote:
> On Wed, Oct 6, 2010 at 6:24 AM, Tom Gall wrote:
>> The code is located here : lp:~tom-gall/linaro-image-tools/rsync-speedup
>>
>> I'm still testing so use with caution.
>>
>> From what I've been able to accomplish thus far, the 67M
>> linaro-headless + hwpack sees the following speed up collected with
>> time:
>>
>> Normal:
>> real10m0.596s
>> user2m2.670s
>> sys 0m9.820s
>>
>> Parallel:
>> real7m58.790s
>> user2m3.170s
>> sys 0m11.950s
>
> nice. do you also have numbers for without hwpack?
I haven't tested without hwpacks. I'm not sure that's a valid test
anymore with the removal of flavors and so on from the builds. Outside
of using an old linaro image, is it valid anymore to call
linaro-media-create without passing hwpacks?
> also ...
>
> rsync -a ${DIR}/binary/etc ${DIR}/binary/usr ${DIR}/binary/lib
> ${DIR}/binary/bin ${DIR}/binary/home ${DIR}/binary/root
> ${DIR}/binary/media ${DIR}/binary/opt ${DIR}/binary/sbin ${ROOT_DISK}
>
> this should at least include /var as well. how about just synching
> everything to be safe?
Well things like dev and proc are in use during the hwpack install so I'd rather
avoid them during the first rsync.
var you make a good point.
Regards,
Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: the linaro toolchain and older arm versions
On Wed, Oct 06, 2010, John Rigby wrote: > I'm really sorry to have started this, but for completeness here is > the rest of the story. No need to be sorry, I think you're doing right to bring this up > The hypothetical scenario is a developer that > maintains u-boot for multiple platforms. Using a codesourcery or eldk > (from denx.de) toolchain one can use the appropriate -march= to get > the right code from the compiler. Also the libgcc.a is ARM so all is > well. Using a linaro toolchain using the same -march= you get the > right code from the compiler but the result will get linked with a > Thumb-2 libgcc.a and the resulting binary will not run on an older > ARM. If however libgcc.a was ARM then it would just work. Again, I'm > not saying this is a bug or even something for Linaro to care about. > It just means that the Linaro toolchain is not something that this > hypothetical u-boot maintainer would want to use as his/her one and > only toolchain. So it strikes me as a toolchain bug; if I understand what you're saying above: - libgcc built with -march=armv7a can be used with ARMv4, v5, v6, v7 CPUs (if you pass the correct -march=), so it's backwards compatible even if libgcc is built with -march=armv7a - libgcc built with -mthumb is NOT compatible with CPUs lacking thumb, even if you pass -marm It gets a bit muddier if one considers that some armv7 CPUs could support Thumb-2 only, but these aren't ARMv7*A*, so I don't think that's relevant for the discussion. I remember we had a similar case for a VFP libgcc back in jaunty, where doko had experienced a multilib VFP libgcc along the regular non-VFP libgcc. Is it purely accidental that libgcc built for -march=armv7 works on older CPUs? Why can't this mechanism be extended to -marm/-mthumb and to VFP options? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: the linaro toolchain and older arm versions
I'm really sorry to have started this, but for completeness here is the rest of the story. The hypothetical scenario is a developer that maintains u-boot for multiple platforms. Using a codesourcery or eldk (from denx.de) toolchain one can use the appropriate -march= to get the right code from the compiler. Also the libgcc.a is ARM so all is well. Using a linaro toolchain using the same -march= you get the right code from the compiler but the result will get linked with a Thumb-2 libgcc.a and the resulting binary will not run on an older ARM. If however libgcc.a was ARM then it would just work. Again, I'm not saying this is a bug or even something for Linaro to care about. It just means that the Linaro toolchain is not something that this hypothetical u-boot maintainer would want to use as his/her one and only toolchain. The naive magical solution would be to for the linker to understand the -march="old non Thumb-2 ARM" and flag an error when linking with a Thumb-2 libgcc.a. Even better would be for the toolchain to have multiple libgcc's and use the right one. The answer is that the developer just needs to know that the libgcc in the Linaro toolchain is Thumb-2 so they must use the libgcc included in the u-boot source when building for old ARM targets. Again, sorry for injecting this noise. My question is answered. John On Wed, Oct 6, 2010 at 6:41 AM, Loïc Minier wrote: > On Tue, Oct 05, 2010, Steve Langasek wrote: >> OOI, what are the U-Boot targets you're looking to build for that don't >> support ARMv7? A gcc multilib package for armel will be easy to implement >> but hard to maintain, and certainly none of the systems Linaro is targeting >> should require a pre-Thumb-2 U-Boot, so I'm very doubtful that the ongoing >> effort to maintain such a toolchain in Ubuntu is justified (unless we find >> that it becomes substantially easier with multiarch, I guess, but we're a >> ways away from that yet). > > Isn't Thumb 2 the actual issue here? U-Boot is built with -marm; does > it cause any issue to mix with our Thumb-2 libgcc? > > -- > Loďc Minier > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq for freescale mx51
On Thu, Sep 30, 2010 at 01:48:17PM +0300, Amit Kucheria wrote:
> Add'ed linaro-dev and linux-arm-kernel to CC.
>
> Thanks Yong, some feeback follows inline.
>
> On 10 Sep 29, Yong Shen wrote:
> > From: Yong Shen
> >
> > ---
> > arch/arm/Kconfig |6 +
> > arch/arm/mach-mx5/Kconfig |1 +
> > arch/arm/mach-mx5/board-mx51_babbage.c | 32
> > arch/arm/mach-mx5/clock-mx51.c | 53 ++
> > arch/arm/plat-mxc/Makefile |2 +
> > arch/arm/plat-mxc/cpufreq.c| 282
> >
> > arch/arm/plat-mxc/include/mach/mxc.h | 20 +++
> > 7 files changed, 396 insertions(+), 0 deletions(-)
> > create mode 100644 arch/arm/plat-mxc/cpufreq.c
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 4db064e..64ebbc0 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1517,6 +1517,12 @@ if ARCH_HAS_CPUFREQ
> >
> > source "drivers/cpufreq/Kconfig"
> >
> > +config CPU_FREQ_IMX
> > + tristate "CPUfreq driver for i.MX CPUs"
> > + depends on ARCH_MXC && CPU_FREQ
> > + help
> > + This enables the CPUfreq driver for i.MX CPUs.
> > +
> > config CPU_FREQ_SA1100
> > bool
> >
> > diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> > index 1576d51..5956fee 100644
> > --- a/arch/arm/mach-mx5/Kconfig
> > +++ b/arch/arm/mach-mx5/Kconfig
> > @@ -5,6 +5,7 @@ config ARCH_MX51
> > default y
> > select MXC_TZIC
> > select ARCH_MXC_IOMUX_V3
> > + select ARCH_HAS_CPUFREQ
> >
> > comment "MX5 platforms:"
> >
> > diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c
> > b/arch/arm/mach-mx5/board-mx51_babbage.c
> > index ed885f9..e449e0b 100644
> > --- a/arch/arm/mach-mx5/board-mx51_babbage.c
> > +++ b/arch/arm/mach-mx5/board-mx51_babbage.c
> > @@ -43,6 +43,31 @@
> > #defineMX51_USB_PLL_DIV_19_2_MHZ 0x01
> > #defineMX51_USB_PLL_DIV_24_MHZ 0x02
> >
> > +struct cpu_wp *(*get_cpu_wp)(int *wp);
This should be moved to a generic place, otherwise it breaks the build
when multiple boards are selected.
> > +static int num_cpu_wp = 2;
>
> use sizeof(array) instead of hard coding this.
>
> > +/* working point(wp): 0 - 800MHz; 1 - 166.25MHz; */
> > +static struct cpu_wp cpu_wp_auto[] = {
> > + {
> > + .pll_rate = 8,
> > + .cpu_rate = 8,
> > + .pdf = 0,
> > + .mfi = 8,
> > + .mfd = 2,
> > + .mfn = 1,
> > + .cpu_podf = 0,
> > + .cpu_voltage = 110,},
> > + {
> > + .pll_rate = 8,
> > + .cpu_rate = 16000,
> > + .pdf = 4,
> > + .mfi = 8,
> > + .mfd = 2,
> > + .mfn = 1,
> > + .cpu_podf = 4,
> > + .cpu_voltage = 85,},
> > +};
>
>
> This data should be moved out to a separate file (e.g. mx51_ratetable.h)
> since it will be useful to other boards too.
>
> If other boards can have different rate tables (and they can, depending on
> the revision of the silicon), then we can either 'assemble' the correct rate
> table based on a flag field or have explicit separate rate tables for each
> silicon revision.
>
> In any case, I suspect that there will be some core rates that will be common
> across silicon revisions.
>
> > static struct platform_device *devices[] __initdata = {
> > &mxc_fec_device,
> > };
> > @@ -87,6 +112,12 @@ static struct imxuart_platform_data uart_pdata = {
> > .flags = IMXUART_HAVE_RTSCTS,
> > };
> >
> > +struct cpu_wp *mx51_babbage_get_cpu_wp(int *wp)
static
> > +{
> > + *wp = num_cpu_wp;
> > + return cpu_wp_auto;
> > +}
> > +
> > static inline void mxc_init_imx_uart(void)
> > {
> > mxc_register_device(&mxc_uart_device0, &uart_pdata);
> > @@ -246,6 +277,7 @@ static void __init mxc_board_init(void)
> >
> > static void __init mx51_babbage_timer_init(void)
> > {
> > + get_cpu_wp = mx51_babbage_get_cpu_wp;
It looks strange to have a global function pointer which gets
overwritten by the boards. I would expect a
imx_add_cpu_workpoints(cpu_wp_auto, ARRAY_SIZE(cpu_wp_auto));
here.
> > mx51_clocks_init(32768, 2400, 22579200, 0);
> > }
> >
> > diff --git a/arch/arm/mach-mx5/clock-mx51.c b/arch/arm/mach-mx5/clock-mx51.c
> > index d9f612d..f2488e6 100644
> > --- a/arch/arm/mach-mx5/clock-mx51.c
> > +++ b/arch/arm/mach-mx5/clock-mx51.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
unneeded include
> >
> > #include
> > #include
> > @@ -28,6 +29,11 @@
> > static unsigned long external_high_reference, external_low_reference;
> > static unsigned long oscillator_reference, ckih2_reference;
> >
> > +extern struct cpu_wp *(*get_cpu_wp)(int *wp);
> > +static int cpu_wp_nr;
> > +static int cpu_curr_wp;
> > +static struct cpu_wp *cpu_wp_tbl;
> > +
> > static struct clk osc_clk;
> > static struct clk pll1_main_clk;
> > static struct clk pll1_sw_clk;
> > @@ -38,7 +44,9 @@ static struct clk periph_apm_clk;
> > static struct clk ahb_clk;
> > static struct clk ipg_clk;
> > static struct c
Re: the linaro toolchain and older arm versions
On Tue, Oct 05, 2010, Steve Langasek wrote: > OOI, what are the U-Boot targets you're looking to build for that don't > support ARMv7? A gcc multilib package for armel will be easy to implement > but hard to maintain, and certainly none of the systems Linaro is targeting > should require a pre-Thumb-2 U-Boot, so I'm very doubtful that the ongoing > effort to maintain such a toolchain in Ubuntu is justified (unless we find > that it becomes substantially easier with multiarch, I guess, but we're a > ways away from that yet). Isn't Thumb 2 the actual issue here? U-Boot is built with -marm; does it cause any issue to mix with our Thumb-2 libgcc? -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
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 your doing but mine) Note that there's still the mmc 0:1 which means first partition and wont work with the other change we're discussing > I guess someone (mattman?) should sign this off and see if everything > is still fine in qemu. It's more Peter looking after QEMU these days; Cc:ing him -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 06, 2010, Alexander Sack wrote: > lp:~asac/linaro-image-tools/boot-snippet-cleanup > > IMO, not requiring initrd feels something that we would want anyway > sooner or later. But no strong opinion for this cycle either way. > > BTW, do you know why the boot.cmd line for beagle IMAGE_FILE case used > root= rather than boot_snippet? was there a bug in qemu about initrd > or just a follow up hack of not using initrd there? I personally find UUID much cleaner than hardcoded device name; it is useful for changing the boot device (e.g. from MMC to USB); for instance, we're discussing moving to rootfs on USB on vexpress -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: the linaro toolchain and older arm versions
On Wednesday 06 October 2010, Steve Langasek wrote: > It sounds like what you need for this is a multilib-enabled armel compiler > build, that includes a libgcc build for ARMv7 as well as separate libgcc > builds for whichever other ARM targets you're after. You should coordinate > this with Marcin (cc:ed), who can help with the toolchain packaging details > for either a native or cross- compiler. The question is how far we want to go, since a real multilib toolchain would require multilib-versions of not only libgcc but also (at least) glibc and libstdc++. The linaro toolchain is currently very much usable to build a pre-v7 kernel and anything that uses -ffreestanding, and IMHO we should try to keep it that way. Would there be anything that we might want to build besides u-boot that requires an matching libgcc but not also an matching glibc? Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 6, 2010 at 1:52 PM, Shawn Guo wrote: > On Wed, Oct 6, 2010 at 7:18 PM, Alexander Sack wrote: >> Re-pushed to same location. I used $MMC2 for root= and $MMC1 for >> UBOOT_PART= in flash-kernel.conf ... haven't tested. >> > Tested it on mx51evk and it works fine. Thanks for confirm. pushed lp:~asac/linaro-image-tools/part-offset-for-non-fs-data-layout to lp:linaro-image-tools (rev 133) -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 6, 2010 at 7:18 PM, Alexander Sack wrote: > Re-pushed to same location. I used $MMC2 for root= and $MMC1 for > UBOOT_PART= in flash-kernel.conf ... haven't tested. > Tested it on mx51evk and it works fine. -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 6, 2010 at 1:46 PM, Alexander Sack wrote: > lp:~asac/linaro-image-tools/unity-omap-bootcmd sorry for the noise. this was a typo. look at: lp:~asac/linaro-image-tools/unify-omap-bootcmd -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 6, 2010 at 1:29 PM, Alexander Sack wrote: > On Wed, Oct 6, 2010 at 1:25 PM, Loïc Minier wrote: >> I think we should use UUID everywhere; in fact, there's a bug about >> lack of usage of an initrd in the image file case open. Note that you >> need initrd support for root=UUID=xyz stuff. > > Hmm ... just made a patch going the other direction: > > lp:~asac/linaro-image-tools/boot-snippet-cleanup Here what would happen if we use UUID everywhere: lp:~asac/linaro-image-tools/unity-omap-bootcmd I guess someone (mattman?) should sign this off and see if everything is still fine in qemu. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 6, 2010 at 1:25 PM, Loïc Minier wrote: > On Wed, Oct 06, 2010, Alexander Sack wrote: >> good catch. will do. i just noticed that we have boot_snippet=UUID=... >> still ... should we fix that to use the /dev/? or rather go for UUID >> everywhere? > > I think we should use UUID everywhere; in fact, there's a bug about > lack of usage of an initrd in the image file case open. Note that you > need initrd support for root=UUID=xyz stuff. Hmm ... just made a patch going the other direction: lp:~asac/linaro-image-tools/boot-snippet-cleanup IMO, not requiring initrd feels something that we would want anyway sooner or later. But no strong opinion for this cycle either way. BTW, do you know why the boot.cmd line for beagle IMAGE_FILE case used root= rather than boot_snippet? was there a bug in qemu about initrd or just a follow up hack of not using initrd there? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpufreq for freescale mx51
On Wednesday 06 October 2010, Yong Shen wrote: > Hi Arnd, > > Really appreciate your valuable comments. Most of them are accepted. I have > different option about two comments. > 1. > > > It would be better to make this code a proper device driver, > > probably a platform_driver unless you have a way to probe > > the presence of the registers on another bus. > > > > Making it a driver that registers to a bus lets you separate > > the probing from the implementation, and gives you a structure > > to add your private variables to. > > > cpufreq is supposed to be registered using cpufreq_register_driver directly, > so no other platform data is needed. You can also find out other cpufreq > driver is designed this way, like omap cpufreq driver. Ok, it is indeed different from what I thought. My thought was that you have resources that need to be attached to a device which then can get matched to a device_driver. However, this is not how it works with the generic clock framework. The device that you are controlling is not a random platform device but the actual CPU, which has a node in the device tree already (/sys/devices/system/cpu/*) and that gets controlled by the generic cpufreq layer, while the resources are tied to the struct clk that you are controlling. So if anything, the clk is what needs to be a platform device, not an artificial cpufreq device. You are only adding another clock to the clock-mx51.c file and you are consistent with the existing clocks in there, so I'm not asking you to change anything here. I wonder however if we can create a common cpufreq driver that would work for all platforms that just need to call clk_set_rate in the end and can operate from platform specific tables otherwise. About half the cpufreq drivers in arm seem to be a variation of this already, so we might be able to make the clock framework good enough for this. > 2. > > > Don't use __raw_readl but readl/ioread32, which have more well-defined > > behaviour. > > > I think __raw_readl is ok here, since in the platform related code, we know > the register layout and length, this is more efficient. Also this is > extensively used in arch/arm/. 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 06, 2010, Alexander Sack wrote: > good catch. will do. i just noticed that we have boot_snippet=UUID=... > still ... should we fix that to use the /dev/? or rather go for UUID > everywhere? I think we should use UUID everywhere; in fact, there's a bug about lack of usage of an initrd in the image file case open. Note that you need initrd support for root=UUID=xyz stuff. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 6, 2010 at 1:04 PM, Alexander Sack wrote: > On Wed, Oct 6, 2010 at 12:58 PM, Loïc Minier 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 >> root=/dev/mmcblk0p2 too > > good catch. will do. i just noticed that we have boot_snippet=UUID=... > still ... should we fix that to use the /dev/? or rather go for UUID > everywhere? > Re-pushed to same location. I used $MMC2 for root= and $MMC1 for UBOOT_PART= in flash-kernel.conf ... haven't tested. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 6, 2010 at 12:58 PM, Loïc Minier 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 > root=/dev/mmcblk0p2 too good catch. will do. i just noticed that we have boot_snippet=UUID=... still ... should we fix that to use the /dev/? or rather go for UUID everywhere? > > Perhaps you could add a comment near MMCOFFSET explaining what it does? > yeah ... thought about that after pushing. will add comments. > Thanks for fixing things up! > -- > Loďc Minier > -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 06, 2010, Shawn Guo wrote: > There is a typo at line 403. The " /dev/mmcblk0p2 63 16064 0 83 Linux > /dev/mmcblk0p1 * 16065 160649 80262c FAT32 LBA > > This is actually the issue I ran into when I was working on mx51evk > support. And I have to make it like the following to get the expected > layout. Ah, I'm not surprized; this is exactly the type of things which pushes me to create a non-FS-data partition to start with; I've added the "10" offset to the branch now I would prefer if we could go with asac's branch though -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
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 explaining what it does? Thanks for fixing things up! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 6, 2010 at 5:28 PM, Loïc Minier wrote: > Ah sorry about that; I've backed out the change in this branch: > lp:~lool/linaro-image-tools/back-out-non-fs-data-partition > would you mind testing it and I'll merge it in mainline if it works as > expected > There is a typo at line 403. The "http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 6, 2010 at 11:28 AM, Loïc Minier wrote: > On Wed, Oct 06, 2010, Shawn Guo wrote: >> That means beagle u-boot will always try to load boot.scr from the >> first partition, which probably makes Non-FS data partition >> implementation fails on beagle. > > Yes; I had backed it out on beagle last week when I realized the same > thing (<20100930102516.ge26...@bee.dooz.org>). > >> I tested the latest l-m-c and found it has problem even with mx51evk. >> As Non-FS data partition was added for mx51evk, the partition id for >> boot_disk and root_disk have to be incremented. > > Ah sorry about that; I've backed out the change in this branch: > lp:~lool/linaro-image-tools/back-out-non-fs-data-partition > would you mind testing it and I'll merge it in mainline if it works as > expected How about something like lp:~asac/linaro-image-tools/part-offset-for-non-fs-data-layout instead of backing out? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Weekly Linaro image testing
On 6 Oct 2010, at 10:19, Shawn Guo wrote: > On Wed, Oct 6, 2010 at 3:04 PM, Jamie Bennett > wrote: >> 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 the page you mentioned. >> >> If you have any problems doing this please get back in contact and I'll help >> you through it. >> > Actually, I do not have problem to set up imx51 image for myself, > since I'm building rootfs from lh build with some changes on the > headless config. But I think a pre-built linaro-headless-imx51 should > be more straight-forward for people on imx51 to go, and better for > everyone testing imx51 on the same page. (Just a thought) Your right, it would be easier. The problem lies with the number of platforms we support and the number of 'flavours' we produce. Lets take a look. Currently we have support in some shape or form for: Beagle Board C3/4 IGEPv2 (slight customisation due to wireless driver) Beagle XM ARM Versatile Express Samsung Ux500 iMX51 We also have these flavours: Headless Netbook ALIP Plasma So if we were to release pre-built images for each board with each flavour, we would need to produce a staggering 24 image and this number is only going to rise. Having a tool to take one board specific part and combine it with one flavour is the most future-proof way of making images. > -- > Regards, > Shawn Regards, Jamie. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Wed, Oct 06, 2010, Shawn Guo wrote: > That means beagle u-boot will always try to load boot.scr from the > first partition, which probably makes Non-FS data partition > implementation fails on beagle. Yes; I had backed it out on beagle last week when I realized the same thing (<20100930102516.ge26...@bee.dooz.org>). > I tested the latest l-m-c and found it has problem even with mx51evk. > As Non-FS data partition was added for mx51evk, the partition id for > boot_disk and root_disk have to be incremented. Ah sorry about that; I've backed out the change in this branch: lp:~lool/linaro-image-tools/back-out-non-fs-data-partition would you mind testing it and I'll merge it in mainline if it works as expected (I don't have mx51evk to test myself) Thanks! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Weekly Linaro image testing
On Wed, Oct 6, 2010 at 3:04 PM, Jamie Bennett wrote: > 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 the page you mentioned. > > If you have any problems doing this please get back in contact and I'll help > you through it. > Actually, I do not have problem to set up imx51 image for myself, since I'm building rootfs from lh build with some changes on the headless config. But I think a pre-built linaro-headless-imx51 should be more straight-forward for people on imx51 to go, and better for everyone testing imx51 on the same page. (Just a thought) -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro-media-create speedup
On Wed, Oct 6, 2010 at 6:24 AM, Tom Gall wrote:
> The code is located here : lp:~tom-gall/linaro-image-tools/rsync-speedup
>
> I'm still testing so use with caution.
>
> From what I've been able to accomplish thus far, the 67M
> linaro-headless + hwpack sees the following speed up collected with
> time:
>
> Normal:
> real 10m0.596s
> user 2m2.670s
> sys 0m9.820s
>
> Parallel:
> real 7m58.790s
> user 2m3.170s
> sys 0m11.950s
nice. do you also have numbers for without hwpack?
also ...
rsync -a ${DIR}/binary/etc ${DIR}/binary/usr ${DIR}/binary/lib
${DIR}/binary/bin ${DIR}/binary/home ${DIR}/binary/root
${DIR}/binary/media ${DIR}/binary/opt ${DIR}/binary/sbin ${ROOT_DISK}
this should at least include /var as well. how about just synching
everything to be safe?
--
- Alexander
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Weekly Linaro image testing
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 the page you mentioned. If you have any problems doing this please get back in contact and I'll help you through it. Regards, Jamie On 6 Oct 2010 03:08, "Shawn Guo" wrote: > On Wed, Sep 29, 2010 at 3:53 PM, Jamie Bennett wrote: >> On Tue, Sep 28, 2010 at 06:50:03PM -0300, Christian Robottom Reis wrote: >>> On Tue, Sep 28, 2010 at 11:28:26AM +0100, Jamie Bennett wrote: >>> > OK, I put together: >>> > >>> > http://wiki.linaro.org/Process/ReleaseTesting >>> >>> Could we add some links to either that page or >>> https://wiki.linaro.org/Releases/1011/WeeklyTesting that explain how >>> testing is supposed to be carried out? >> >> I've added a few links to the Process/ReleaseTesting page which should >> help explaining how to test the images. >> > Great guide on https://wiki.linaro.org/Releases/DailyBuilds. But I > can not find image like linaro-headless-imx51 on > http://snapshots.linaro.org/10.11-daily/ to start testing on imx51. > > -- > Regards, > Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
