Re: [RFC] Upcoming work view for individual engineers
On Thu, Feb 2, 2012 at 4:24 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hey, On Wed, Feb 1, 2012 at 1:54 PM, Guilherme Salgado guilherme.salg...@linaro.org wrote: Hi folks, We're trying to make status.l.o more useful to engineers and the first thing we're planning to do is a new page listing the upcoming work assigned to a given person. I'm attaching a mockup of that view here and we'd like to know what you think of it... Do you think that would be useful to you? Is there any other information you'd like to see there, or maybe a different way to present/group them? Awesome, that looks a lot better from what we have now, and easier to read. Just a few questions and comments: 1 - Are we tracking bugs that are not assigned to a milestone? The engineer's view shows upcoming work by showing the most urgent work on top, that is by nearest deadline (unless something is blocked). It would be tricky to determine when that work is due if a bug is not targeted to a milestone. Perhaps all bugs assigned to this person, but not targeted to a milestone should be listed by themselves somewhere further down the page? 2 - What will happen when the cycle is finished, but there are still WIs to be done? Our PM usually kindly reminds me about those WIs and I get the option to complete them or split them off to a new blueprint for next cycle. Moving the entire blueprint to the next milestone would probably be ok too. So work items that are not done or postponed should not get stuck on a blueprint for a finished cycle, right? 3 - While I see that is useful to see what was already done for a cycle, for me I believe this view should behave similarly as a TODO list, that once something is done, it's either removed from the view, or changed in a way it'll not get much attention as the ones that are still to be done. 4 - Do you know if a similar page, but for a team, will also be available? There will be. Guilherme has circulated a mockup for that too, on the techleads list. Thanks -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v7 0/4] Add SMDK5250 board support
This patchset add support for Samsung's SMDK5250 board based on EXYNOS5250 based SoC. It also adds support for MMC SPL booting. The porting is done by Samsung engineers at HQ in System LSI Team. I am contributing in upstreaming the code for the board. Based upon discussions following patches are dropped in this version: Exynos: Add CONFIG_EXYNOS4 Macro to EXYNOS4 based boards Exynos: Clock.c: Replace exynos4 prefix with exynos SMDK5250: enable device tree support is squashed with EXYNOS: Add SMDK5250 board support Chander Kashyap (4): Exynos: Clock.c: Use CONFIG_SYS_CLK_FREQ macro ARM: EXYNOS: Add support for Exynos5 based SoCs EXYNOS: Add SMDK5250 board support EXYNOS: SMDK5250: Add MMC SPL support MAINTAINERS |1 + arch/arm/cpu/armv7/exynos/clock.c | 214 +++- arch/arm/include/asm/arch-exynos/clock.h | 326 ++ arch/arm/include/asm/arch-exynos/cpu.h| 35 ++- arch/arm/include/asm/arch-exynos/dmc.h| 146 arch/arm/include/asm/arch-exynos/gpio.h | 99 +- arch/arm/include/asm/arch-exynos/tzpc.h | 52 +++ board/samsung/smdk5250/Makefile | 67 board/samsung/smdk5250/clock_init.c | 202 +++ board/samsung/smdk5250/dmc_init.c | 453 + board/samsung/smdk5250/lowlevel_init.S| 96 ++ board/samsung/smdk5250/mmc_boot.c | 58 board/samsung/smdk5250/setup.h| 448 board/samsung/smdk5250/smdk5250.c | 146 board/samsung/smdk5250/tools/mkexynos_image.c | 117 +++ board/samsung/smdk5250/tzpc_init.c| 48 +++ boards.cfg|1 + include/configs/s5pc210_universal.h |1 + include/configs/smdk5250.h| 197 +++ include/configs/trats.h |1 + 20 files changed, 2691 insertions(+), 17 deletions(-) create mode 100644 arch/arm/include/asm/arch-exynos/dmc.h create mode 100644 arch/arm/include/asm/arch-exynos/tzpc.h create mode 100644 board/samsung/smdk5250/Makefile create mode 100644 board/samsung/smdk5250/clock_init.c create mode 100644 board/samsung/smdk5250/dmc_init.c create mode 100644 board/samsung/smdk5250/lowlevel_init.S create mode 100644 board/samsung/smdk5250/mmc_boot.c create mode 100644 board/samsung/smdk5250/setup.h create mode 100644 board/samsung/smdk5250/smdk5250.c create mode 100644 board/samsung/smdk5250/tools/mkexynos_image.c create mode 100644 board/samsung/smdk5250/tzpc_init.c create mode 100644 include/configs/smdk5250.h -- 1.7.5.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v7 4/4] EXYNOS: SMDK5250: Add MMC SPL support
This patch adds support for MMC SPL booting.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
Changes for v6:
- None
Changes for v7:
- None
board/samsung/smdk5250/Makefile | 16
board/samsung/smdk5250/mmc_boot.c | 58
board/samsung/smdk5250/tools/mkexynos_image.c | 117 +
include/configs/smdk5250.h|7 ++
4 files changed, 198 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/smdk5250/mmc_boot.c
create mode 100644 board/samsung/smdk5250/tools/mkexynos_image.c
diff --git a/board/samsung/smdk5250/Makefile b/board/samsung/smdk5250/Makefile
index 80e8be3..9bba6e7 100644
--- a/board/samsung/smdk5250/Makefile
+++ b/board/samsung/smdk5250/Makefile
@@ -29,18 +29,34 @@ SOBJS := lowlevel_init.o
COBJS := clock_init.o
COBJS += dmc_init.o
COBJS += tzpc_init.o
+
+ifndef CONFIG_SPL_BUILD
COBJS += smdk5250.o
+endif
+
+ifdef CONFIG_SPL_BUILD
+COBJS += mmc_boot.o
+endif
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
ALL:= $(obj).depend $(LIB)
+ifdef CONFIG_SPL_BUILD
+ALL+= $(OBJTREE)/tools/mk$(BOARD)spl
+endif
+
all: $(ALL)
$(LIB):$(OBJS)
$(call cmd_link_o_target, $(OBJS))
+ifdef CONFIG_SPL_BUILD
+$(OBJTREE)/tools/mk$(BOARD)spl:tools/mkexynos_image.c
+ $(HOSTCC) tools/mkexynos_image.c -o $(OBJTREE)/tools/mk$(BOARD)spl
+endif
+
#
# defines $(obj).depend target
diff --git a/board/samsung/smdk5250/mmc_boot.c
b/board/samsung/smdk5250/mmc_boot.c
new file mode 100644
index 000..449a919
--- /dev/null
+++ b/board/samsung/smdk5250/mmc_boot.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#includecommon.h
+#includeconfig.h
+
+/*
+* Copy U-boot from mmc to RAM:
+* COPY_BL2_FNPTR_ADDR: Address in iRAM, which Contains
+* Pointer to API (Data transfer from mmc to ram)
+*/
+void copy_uboot_to_ram(void)
+{
+ u32 (*copy_bl2)(u32, u32, u32) = (void *) *(u32 *)COPY_BL2_FNPTR_ADDR;
+
+ copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT, CONFIG_SYS_TEXT_BASE);
+}
+
+void board_init_f(unsigned long bootflag)
+{
+ __attribute__((noreturn)) void (*uboot)(void);
+ copy_uboot_to_ram();
+
+ /* Jump to U-Boot image */
+ uboot = (void *)CONFIG_SYS_TEXT_BASE;
+ (*uboot)();
+ /* Never returns Here */
+}
+
+/* Place Holders */
+void board_init_r(gd_t *id, ulong dest_addr)
+{
+ /* Function attribute is no-return */
+ /* This Function never executes */
+ while (1)
+ ;
+}
+
+void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3) {}
diff --git a/board/samsung/smdk5250/tools/mkexynos_image.c
b/board/samsung/smdk5250/tools/mkexynos_image.c
new file mode 100644
index 000..3159e7c
--- /dev/null
+++ b/board/samsung/smdk5250/tools/mkexynos_image.c
@@ -0,0 +1,117 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include fcntl.h
+#include errno.h
+#include string.h
+#include sys/stat.h
+
+#define CHECKSUM_OFFSET(14*1024-4)
+#define
[PATCH v7 1/4] Exynos: Clock.c: Use CONFIG_SYS_CLK_FREQ macro
CONFIG_SYS_CLK_FREQ_C210 macro giving notion of S5PC2XX (Exynos4)
architecture. Replace CONFIG_SYS_CLK_FREQ_C210 with CONFIG_SYS_CLK_FREQ
to make it generic for exynos architecture.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
Changes for v2:
- None
Changes for v3:
- None
Changes for V4:
- Added CONFIG_SYS_CLK_FREQ to trats.h
Changes for v5:
- None
Changes for v6:
- None
Changes for v7:
- None
arch/arm/cpu/armv7/exynos/clock.c |6 +-
include/configs/s5pc210_universal.h |1 +
include/configs/trats.h |1 +
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 0c199cd..4d92c53 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -26,10 +26,6 @@
#include asm/arch/clock.h
#include asm/arch/clk.h
-#ifndef CONFIG_SYS_CLK_FREQ_C210
-#define CONFIG_SYS_CLK_FREQ_C210 2400
-#endif
-
/* exynos4: return pll clock frequency */
static unsigned long exynos4_get_pll_clk(int pllreg)
{
@@ -76,7 +72,7 @@ static unsigned long exynos4_get_pll_clk(int pllreg)
/* SDIV [2:0] */
s = r 0x7;
- freq = CONFIG_SYS_CLK_FREQ_C210;
+ freq = CONFIG_SYS_CLK_FREQ;
if (pllreg == EPLL) {
k = k 0x;
diff --git a/include/configs/s5pc210_universal.h
b/include/configs/s5pc210_universal.h
index be000cb..8286680 100644
--- a/include/configs/s5pc210_universal.h
+++ b/include/configs/s5pc210_universal.h
@@ -49,6 +49,7 @@
/* input clock of PLL: Universal has 24MHz input clock at EXYNOS4210 */
#define CONFIG_SYS_CLK_FREQ_C210 2400
+#define CONFIG_SYS_CLK_FREQCONFIG_SYS_CLK_FREQ_C210
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_CMDLINE_TAG
diff --git a/include/configs/trats.h b/include/configs/trats.h
index acb3241..10f11d9 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -49,6 +49,7 @@
/* input clock of PLL: TRATS has 24MHz input clock at EXYNOS4210 */
#define CONFIG_SYS_CLK_FREQ_C210 2400
+#define CONFIG_SYS_CLK_FREQCONFIG_SYS_CLK_FREQ_C210
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_CMDLINE_TAG
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v7 2/4] ARM: EXYNOS: Add support for Exynos5 based SoCs
Samsung's ARM Cortex-A15 based SoCs are known as Exynos5 series of
SoCs. This patch adds the support for Exynos5.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
Changes for v2:
- This patch was part of EXYNOS: Add SMDK5250 board support
- Now it is seprated as SoC support.
Changes for v3:
- Populated complete exynos5 gpio structures
Changes for v4:
- Added dmc.h and tzpc.h header files
- Renamed EXYNOS5_PHY*_CTRL_BASE to EXYNOS5_DMC_PHY*_BASE
Changes for v5:
- None
Changes for v6:
- None
Changes for v7:
- None
arch/arm/cpu/armv7/exynos/clock.c| 208 +++-
arch/arm/include/asm/arch-exynos/clock.h | 326 ++
arch/arm/include/asm/arch-exynos/cpu.h | 35 +++-
arch/arm/include/asm/arch-exynos/dmc.h | 146 +
arch/arm/include/asm/arch-exynos/gpio.h | 99 +-
arch/arm/include/asm/arch-exynos/tzpc.h | 52 +
6 files changed, 854 insertions(+), 12 deletions(-)
create mode 100644 arch/arm/include/asm/arch-exynos/dmc.h
create mode 100644 arch/arm/include/asm/arch-exynos/tzpc.h
diff --git a/arch/arm/cpu/armv7/exynos/clock.c
b/arch/arm/cpu/armv7/exynos/clock.c
index 4d92c53..2f7048b 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -92,6 +92,72 @@ static unsigned long exynos4_get_pll_clk(int pllreg)
return fout;
}
+/* exynos5: return pll clock frequency */
+static unsigned long exynos5_get_pll_clk(int pllreg)
+{
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+ unsigned long r, m, p, s, k = 0, mask, fout;
+ unsigned int freq;
+
+ switch (pllreg) {
+ case APLL:
+ r = readl(clk-apll_con0);
+ break;
+ case MPLL:
+ r = readl(clk-mpll_con0);
+ break;
+ case EPLL:
+ r = readl(clk-epll_con0);
+ k = readl(clk-epll_con1);
+ break;
+ case VPLL:
+ r = readl(clk-vpll_con0);
+ k = readl(clk-vpll_con1);
+ break;
+ default:
+ printf(Unsupported PLL (%d)\n, pllreg);
+ return 0;
+ }
+
+ /*
+* APLL_CON: MIDV [25:16]
+* MPLL_CON: MIDV [25:16]
+* EPLL_CON: MIDV [24:16]
+* VPLL_CON: MIDV [24:16]
+*/
+ if (pllreg == APLL || pllreg == MPLL)
+ mask = 0x3ff;
+ else
+ mask = 0x1ff;
+
+ m = (r 16) mask;
+
+ /* PDIV [13:8] */
+ p = (r 8) 0x3f;
+ /* SDIV [2:0] */
+ s = r 0x7;
+
+ freq = CONFIG_SYS_CLK_FREQ;
+
+ if (pllreg == EPLL) {
+ k = k 0x;
+ /* FOUT = (MDIV + K / 65536) * FIN / (PDIV * 2^SDIV) */
+ fout = (m + k / 65536) * (freq / (p * (1 s)));
+ } else if (pllreg == VPLL) {
+ k = k 0xfff;
+ /* FOUT = (MDIV + K / 1024) * FIN / (PDIV * 2^SDIV) */
+ fout = (m + k / 1024) * (freq / (p * (1 s)));
+ } else {
+ if (s 1)
+ s = 1;
+ /* FOUT = MDIV * FIN / (PDIV * 2^(SDIV - 1)) */
+ fout = m * (freq / (p * (1 (s - 1;
+ }
+
+ return fout;
+}
+
/* exynos4: return ARM clock frequency */
static unsigned long exynos4_get_arm_clk(void)
{
@@ -114,6 +180,28 @@ static unsigned long exynos4_get_arm_clk(void)
return armclk;
}
+/* exynos5: return ARM clock frequency */
+static unsigned long exynos5_get_arm_clk(void)
+{
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+ unsigned long div;
+ unsigned long armclk;
+ unsigned int arm_ratio;
+ unsigned int arm2_ratio;
+
+ div = readl(clk-div_cpu0);
+
+ /* ARM_RATIO: [2:0], ARM2_RATIO: [30:28] */
+ arm_ratio = (div 0) 0x7;
+ arm2_ratio = (div 28) 0x7;
+
+ armclk = get_pll_clk(APLL) / (arm_ratio + 1);
+ armclk /= (arm2_ratio + 1);
+
+ return armclk;
+}
+
/* exynos4: return pwm clock frequency */
static unsigned long exynos4_get_pwm_clk(void)
{
@@ -157,6 +245,27 @@ static unsigned long exynos4_get_pwm_clk(void)
return pclk;
}
+/* exynos5: return pwm clock frequency */
+static unsigned long exynos5_get_pwm_clk(void)
+{
+ struct exynos5_clock *clk =
+ (struct exynos5_clock *)samsung_get_base_clock();
+ unsigned long pclk, sclk;
+ unsigned int ratio;
+
+ /*
+* CLK_DIV_PERIC3
+* PWM_RATIO [3:0]
+*/
+ ratio = readl(clk-div_peric3);
+ ratio = ratio 0xf;
+ sclk = get_pll_clk(MPLL);
+
+ pclk = sclk / (ratio + 1);
+
+ return pclk;
+}
+
/* exynos4: return uart clock frequency */
static unsigned long exynos4_get_uart_clk(int dev_index)
{
@@ -204,6 +313,53 @@ static unsigned long
[PATCH v7 3/4] EXYNOS: Add SMDK5250 board support
SMDK5250 board is based on Samsungs EXYNOS5250 SoC. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- Changes for v2: - This patch is bifurcated into borad support and SoC support - Fixed typo: s/EEYNOS/EXYNOS - Squashed patch SMDK5250: enable device tree support in this. Changes for v3: - None Changes for v4: - Converted assembly routines for clock, memory, uart and tzpc - init to c functions - Moved uart init to smdk5250.c Changes for v5: - Remove init of gpio1 - Fixed gpio configuration for uart Changes for v6: - Add gpio1 init in board_uart_init, which was removed in v5 Changes for v7: - Converted magic numbers in dmc_init.c with macro defines - Divided mem_ctrl_init() function in dmc_init.c in smaller modules. - Removed init of all uarts except uart2 in smdk5250.c file. - Removed values assigned for boolean defines. - Removed back-slashes used for continuation in smdk5250.c MAINTAINERS|1 + board/samsung/smdk5250/Makefile| 51 board/samsung/smdk5250/clock_init.c| 202 ++ board/samsung/smdk5250/dmc_init.c | 453 board/samsung/smdk5250/lowlevel_init.S | 96 +++ board/samsung/smdk5250/setup.h | 448 +++ board/samsung/smdk5250/smdk5250.c | 146 ++ board/samsung/smdk5250/tzpc_init.c | 48 boards.cfg |1 + include/configs/smdk5250.h | 190 + 10 files changed, 1636 insertions(+), 0 deletions(-) create mode 100644 board/samsung/smdk5250/Makefile create mode 100644 board/samsung/smdk5250/clock_init.c create mode 100644 board/samsung/smdk5250/dmc_init.c create mode 100644 board/samsung/smdk5250/lowlevel_init.S create mode 100644 board/samsung/smdk5250/setup.h create mode 100644 board/samsung/smdk5250/smdk5250.c create mode 100644 board/samsung/smdk5250/tzpc_init.c create mode 100644 include/configs/smdk5250.h diff --git a/MAINTAINERS b/MAINTAINERS index a05ad46..f88a282 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -713,6 +713,7 @@ Chander Kashyap k.chan...@samsung.com origen ARM ARMV7 (EXYNOS4210 SoC) SMDKV310ARM ARMV7 (EXYNOS4210 SoC) + SMDK5250ARM ARMV7 (EXYNOS5250 SoC) Heungjun Kim riverful@samsung.com diff --git a/board/samsung/smdk5250/Makefile b/board/samsung/smdk5250/Makefile new file mode 100644 index 000..80e8be3 --- /dev/null +++ b/board/samsung/smdk5250/Makefile @@ -0,0 +1,51 @@ +# +# Copyright (C) 2012 Samsung Electronics +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +SOBJS := lowlevel_init.o + +COBJS := clock_init.o +COBJS += dmc_init.o +COBJS += tzpc_init.o +COBJS += smdk5250.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) + +ALL:= $(obj).depend $(LIB) + +all: $(ALL) + +$(LIB):$(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/samsung/smdk5250/clock_init.c b/board/samsung/smdk5250/clock_init.c new file mode 100644 index 000..3395005 --- /dev/null +++ b/board/samsung/smdk5250/clock_init.c @@ -0,0 +1,202 @@ +/* + * Clock setup for SMDK5250 board based on EXYNOS5 + * + * Copyright (C) 2012 Samsung Electronics + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A
Re: [RFC PATCH 2/2] thermal: Add generic cpu cooling implementation
On 1 February 2012 20:27, Matthew Garrett m...@redhat.com wrote: On Tue, Dec 13, 2011 at 08:43:16PM +0530, Amit Daniel Kachhap wrote: This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling and cpuhotplugg currently. We've been over this kind of thing in the past. cpu hotplug is a relatively expensive operation, so people have previously been enthusiastic about using the scheduler to simply avoid running anything on CPUs if they're overheating. Has any general consensus been reached on this? yes you are right that cpuhotplug is an expensive process and it may further heat up the system before turning off so the ideal way would be to reduce the capacity of the cpu gradually. Anyway these patches are only exporting those API's and the actual use of them depends on the user. Although my bigger focus is on cpufreq as cooling devices so I might remove cpuhotplug in the next version. I'm also not entirely thrilled at now having two ways to manage the cpu through the thermal layer. ACPI already plugs in via the passive trip points. If we're going to do this then I'd like to see the ACPI code merged in with the generic cpu cooling code. Yeah I also agree that there is a kind of repetition and not entirely sure where to place these codes. I will try adding them inside acpi. Thanks for the suggestion. -- Matthew Garrett | mj...@srcf.ucam.org ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Linaro Android against vanilla linux kernel versions
Hi I have already asked thi question at http://ask.linaro.org/questions/607/looking-for-android-distribution-bui ld-on-top-of-linux-kernel-26359-for-imx53-board http://ask.linaro.org/questions/607/looking-for-android-distribution-bu ild-on-top-of-linux-kernel-26359-for-imx53-board but could not receive satisfactory answer. Exactly how can you determine against which vanilla linux kernel version linaro Android distribution is built ? Thanks for your support BR Tugrul ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Upcoming work view for individual engineers
On 2 February 2012 08:28, Mattias Backman mattias.back...@linaro.org wrote: On Thu, Feb 2, 2012 at 4:24 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: 4 - Do you know if a similar page, but for a team, will also be available? There will be. Guilherme has circulated a mockup for that too, on the techleads list. Is there going to be a way of viewing project-level todo stuff? I'm thinking about (a) show me all the QEMU related things (just-me-personally is too narrow, and whole-toolchain-group is too wide), and (b) KVM work, which is likely to span multiple cards, working groups, blueprints and engineers. Feel free to say that's an uncommon use case and we're going to ignore it :-) -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Upcoming work view for individual engineers
On 02/02/12 12:28, Peter Maydell wrote: On 2 February 2012 08:28, Mattias Backman mattias.back...@linaro.org wrote: On Thu, Feb 2, 2012 at 4:24 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: 4 - Do you know if a similar page, but for a team, will also be available? There will be. Guilherme has circulated a mockup for that too, on the techleads list. Is there going to be a way of viewing project-level todo stuff? I'm thinking about (a) show me all the QEMU related things (just-me-personally is too narrow, and whole-toolchain-group is too wide), and (b) KVM work, which is likely to span multiple cards, working groups, blueprints and engineers. We don't have any plans for that as the time we have to work on this stuff is barely enough for the person/team pages. However, we've already started teaching Launchpad about Blueprint work-items and once that's done it'd be straightforward to extend a page like https://launchpad.net/qemu-linaro/+milestone/2012.02 to show the progress based on the state of work-items. Feel free to say that's an uncommon use case and we're going to ignore it :-) I'm sure it's a common use case and there are more people who would appreciate to have a view like that in LP. -- Guilherme Salgado https://launchpad.net/~salgado signature.asc Description: OpenPGP digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: native gdb for Android
Barry Song 21cn...@gmail.com wrote: So my questions are: 1. Should I compile the native gdb using android toolchain and android bionic/libthread libraries? 2. Why can’t the current gdb capture multithreads for android processes? This question is actually about the theory for gdb to know multi-threads. In my opinion, both gnu and android use clone() to fork threads and threads in one process have same tgid in kernel and all threads return same getpid() value. Why not gdb just travel process lists to find multi-threads? I'm not sure what exactly is going on on Android with bionic. However, GDB currently does require support from the thread library in order to debug multi-threaded applications. This is needed e.g. to properly handle thread-local storage variables. GDB will also use this support to detect threads of a running process it is attaching to. (It is true that GDB *could* e.g. look at /proc to find threads, instead of inspecting thread library data structures. However, since the link to those data structures is required anyway, e.g. for TLS, this has not been implemented so far ...) When using glibc's libpthread, the support routines gdb uses to inspect target thread library datastructures are provided in libthread_db.so.1 (which comes with glibc, and is linked into gdb). I do not know the details on whether/how bionic provides a corresponding service. However, from looking at the gdbserver sources provided with Android, it seems there are some differences; in particular, there's this patch: +/* Android doesn't have libthread_db.so.1, just libthread_db.so. */ +#ifdef __ANDROID__ +#define LIBTHREAD_DB_SO libthread_db.so +#endif + If libthread_db is named differently, this would explain why GDB is unable to find and use it. 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 Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Template
And if you want to upload it to Google docs, then do the following steps, otherwise, there will be no pre-view. 1. Open Linaro-Template.odp with openoffice.org presentation; 2. Save it as ppt format; 3. Upload this ppt file to Google Docs. FYI. On Thu, Feb 2, 2012 at 1:51 AM, Zach Pfeffer zach.pfef...@linaro.orgwrote: If anyone needs a template for presentations, this one looks nice. Thank Tony! -- Forwarded message -- From: Tony Mansson tony.mans...@linaro.org Date: 1 February 2012 11:44 Subject: Template To: Botao Sun botao@linaro.org, Bernhard Rosenkranzer bernhard.rosenkran...@linaro.org, Vishal Bhoj vishal.b...@linaro.org, Zach Pfeffer zach.pfef...@linaro.org, Amit Pundir amit.pun...@linaro.org Here, use this as template. -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-android mailing list linaro-andr...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-android ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH v4 2/4] ARM: omap: Remove cpuidle timekeeping and irq enable/disable
On Thu, Feb 2, 2012 at 10:21 AM, Jean Pihet jean.pi...@newoldbits.com wrote:
Rob,
On Wed, Feb 1, 2012 at 4:00 AM, Robert Lee rob@linaro.org wrote:
Now that the core cpuidle driver keeps time and handles irq enabling,
remove this functionality. Also, remove irq disabling as all paths to
cpuidle_idle_call already call local_irq_disable. Also, restructure
idle functions as needed by the cpuidle core driver changes.
Signed-off-by: Robert Lee rob@linaro.org
---
arch/arm/mach-omap2/cpuidle34xx.c | 96
1 files changed, 43 insertions(+), 53 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 464cffd..9ecded5 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
...
@@ -100,23 +107,20 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- struct omap3_idle_statedata *cx =
- cpuidle_get_statedata(dev-states_usage[index]);
- struct timespec ts_preidle, ts_postidle, ts_idle;
- u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
- int idle_time;
+ struct omap3_idle_drvdata *dd = dev-states_usage[index].driver_data
A build error is triggered by the missing ;.
Argh, last minute change and I didn't build afterward.
...
@@ -147,18 +151,12 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
pwrdm_for_each_clkdm(core_pd, _cpuidle_allow_idle);
}
-return_sleep_time:
- getnstimeofday(ts_postidle);
- ts_idle = timespec_sub(ts_postidle, ts_preidle);
-
- local_irq_enable();
+leave:
local_fiq_enable();
- idle_time = ts_idle.tv_nsec / NSEC_PER_USEC + ts_idle.tv_sec * \
- USEC_PER_SEC;
-
- /* Update cpuidle counters */
- dev-last_residency = idle_time;
+ /* Restore original PER state if it was modified */
+ if (dd-per_next_state != dd-per_saved_state)
+ pwrdm_set_next_pwrst(per_pd, dd-per_saved_state);
This code is not necessarily balanced with the PER state change in
omap3_enter_idle_bm (cf. /* Are we changing PER target state? */
here below), since in the core cpuidle code there is no guarantee that
the calls to pre_enter and enter callbacks are balanced.
In general I fear that splitting the code in two functions introduces
a risk of programming non-coherent settings in the PRCM.
Agree, in general it does introduce that new risk. For the platform
code changes, I tried to keep the code paths the same as before. I
see now where I created a problem though:
...
if (target_state-pre_enter) {
idx = target_state-
pre_enter(dev, drv, idx);
}
if (idx 0) {
local_irq_enable();
return idx;
}
if (need_resched()) {
local_irq_enable();
return -EBUSY;
}
...
The only way the core cpuidle pre_enter can get called without enter
without enter is if the omap3 next_valid_state() returned a negative
value. If this ever happened in the existing omap3 code, it would
cause it to break anyway. But, this particular need_resched() call
could cause an exit that results in difference behavior than before.
One solution to that is just to move the need_resched check before the
pre_enter call.
...
@@ -255,8 +255,9 @@ static int omap3_enter_idle_bm(struct cpuidle_device
*dev,
int index)
{
int new_state_idx;
- u32 core_next_state, per_next_state = 0, per_saved_state = 0,
cam_state;
- struct omap3_idle_statedata *cx;
+ u32 core_next_state, cam_state;
+ struct omap3_idle_drvdata *dd = dev-states_usage[index].driver_data;
+ struct omap3_idle_statedata *cx = dd-state_data[index];
int ret;
The build throws a few warnings about unused variables:
arch/arm/mach-omap2/cpuidle34xx.c: In function 'omap3_enter_idle_bm':
arch/arm/mach-omap2/cpuidle34xx.c:261: warning: unused variable 'ret'
arch/arm/mach-omap2/cpuidle34xx.c:257: warning: unused variable
'new_state_idx'
...
Got it, not sure why I missed this.
DEFINE_PER_CPU(struct cpuidle_device, omap3_idle_dev);
@@ -337,7 +329,8 @@ static inline void _fill_cstate(struct cpuidle_driver
*drv,
state-exit_latency = cpuidle_params_table[idx].exit_latency;
state-target_residency = cpuidle_params_table[idx].target_residency;
state-flags = CPUIDLE_FLAG_TIME_VALID;
- state-enter = omap3_enter_idle_bm;
+ state-pre_enter = omap3_enter_idle_bm;
+ state-enter = omap3_enter_idle;
sprintf(state-name, C%d, idx + 1);
strncpy(state-desc, descr,
ubuntu-desktop/sources.txt bug/typo?
Hi, I've noticed what looks like a bug/typo in http://releases.linaro.org/images/12.01/oneiric/ubuntu-desktop/sources.txt and I wonder if this is the right place to report it? Thanks. The last entry has linarotv-xbmc where I would expect ubuntu-desktop: ... panda-ubuntu-desktop: http://releases.linaro.org/12.01/ubuntu/oneiric-hwpacks/ hwpack_linaro-lt-panda-x11-base_20120123-1_armel_supported.tar.gz: md5sum(4dae5fc312b4e0a73d81511e4e4b1e55) http://releases.linaro.org/12.01/ubuntu/oneiric-images/ubuntu-desktop linaro-o-linarotv-xbmc-tar-20120125-0.tar.gz: md5sum(e27e3af3d00eefa5f64f72f990482053) -- 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.___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Connect Sessions from the Developer Platform Team
Another important one :-) Maximizing the usefulness of the LEB for customers and members https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-maximizing-usefulness-leb Goal is to get feedback from people consuming our LEBs, so we can understand better what we need to improve to make them even more useful. Thanks, On Tue, Jan 31, 2012 at 1:11 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hey folks, As usual, follows a list of the sessions the Developer Platform Team will lead at this Connect: Ubuntu LEB and LAVA: Current status and future planning for proper image testing and validation https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-lava-and-ubuntu-leb-testing-validation Improvements and future discussions for LTs and the Ubuntu LEB https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-lt-platform-discussions Packaged Kernel CI: Current Status and Next Steps https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-packaged-kernel-ci-next-steps Sysroots: Automation, Maintenance and Future Work https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-sysroots-automation-maintenance U-Boot-Linaro Future Planning https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-u-boot-linaro-future-future-planning Developer Platform: Future Planning https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-dev-plat-future-planning Cross Build with Multi-Arch: Current state and future planning https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-cross-multi-arch-support Please make sure you subscribe to the ones you'd like to attend, and also add yourself as 'essential' to the ones you really like to participate (so the scheduler can find a free spot that's also available for you). This is not yet the final list, as we'll probably have additional ones until the end of the week, but you can always look for all the sessions related with the Developer Platform Team at https://blueprints.launchpad.net/linaro-ubuntu?searchtext=linaro-platforms-q112 Thanks, -- Ricardo Salveti de Araujo -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ubuntu-desktop/sources.txt bug/typo?
On 02/02/2012 11:43 AM, Scott Douglass wrote: Hi, I’ve noticed what looks like a bug/typo in http://releases.linaro.org/images/12.01/oneiric/ubuntu-desktop/sources.txt and I wonder if this is the right place to report it? Thanks. This is the correct place. I just fixed the issue. The last entry has “linarotv-xbmc” where I would expect “ubuntu-desktop”: ... panda-ubuntu-desktop: http://releases.linaro.org/12.01/ubuntu/oneiric-hwpacks/ hwpack_linaro-lt-panda-x11-base_20120123-1_armel_supported.tar.gz: md5sum(4dae5fc312b4e0a73d81511e4e4b1e55) http://releases.linaro.org/12.01/ubuntu/oneiric-images/ubuntu-desktop linaro-o-linarotv-xbmc-tar-20120125-0.tar.gz: md5sum(e27e3af3d00eefa5f64f72f990482053) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: native gdb for Android
Hi Barry, On Thu, 2012-02-02 at 10:23 +0800, Barry Song wrote: 2.Why can’t the current gdb capture multithreads for android processes? This question is actually about the theory for gdb to know multi-threads. In my opinion, both gnu and android use clone() to fork threads and threads in one process have same tgid in kernel and all threads return same getpid() value. Why not gdb just travel process lists to find multi-threads? Would you mind opening a bug report at https://bugs.launchpad.net/gdb-linaro with this issue? If possible, with a small testcase to reproduce the problem, and the steps to build the testcase. To be honest I can only look into this issue late next week though... -- []'s Thiago Jung Bauermann Linaro Toolchain Working Group ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro Android against vanilla linux kernel versions
Hello Tugrul, On Thu, 2 Feb 2012 16:12:29 +0200 Guclu, Tugrul tugrul.gu...@siemens.com wrote: Hi I have already asked thi question at http://ask.linaro.org/questions/607/looking-for-android-distribution-bui ld-on-top-of-linux-kernel-26359-for-imx53-board http://ask.linaro.org/questions/607/looking-for-android-distribution-bu ild-on-top-of-linux-kernel-26359-for-imx53-board but could not receive satisfactory answer. Exactly how can you determine against which vanilla linux kernel version linaro Android distribution is built ? Unfortunately, Android doesn't offer any kind of package management or even manifesting to make answering such question easy. We're aware of this issue, and would like to do something about it, but it has low priority, as it's unclear if that would be accepted upstream and we try not to deviate much from AOSP. So, that leaves with just tracing needed info thru binaries or sources. And as Android is big, that's a bit of chore. Let's go source way as an example. Suppose you want to figure out with which kernel version this and exactly this build was made (because all components including kernel change over time): https://android-build.linaro.org/builds/~linaro-android/imx53-ics-gcc46-freescalelt-stable-open/#build=178 So, open pinned-manifest.xml from that page, which has exactly component revisions used in the build. Look for kernel: project name=kernel/imx53 path=kernel revision=8083fb279331e989d3d98a71ba6273f803ed7b96/ That comes from default remote which is remote fetch=git://android.git.linaro.org/ name=aosp review=review.android.git.linaro.org/ default remote=aosp revision=refs/tags/android-4.0.3_r1 sync-j=4/ (don't pay attention to aosp, in this context it means Linaro's extended mirror of AOSP). That remote has git web on the same URL (which is good convention), let's look for kernel/imx53 repository there: http://android.git.linaro.org/gitweb?p=kernel/imx53.git;a=summary Let's search for the revision from pinned-manifest.xml: http://android.git.linaro.org/gitweb?p=kernel%2Fimx53.gita=searchh=HEADst=commits=8083fb279331e989d3d98a71ba6273f803ed7b96 What we're interested in is however the tree which corresponds to this revision (click tree link): http://android.git.linaro.org/gitweb?p=kernel/imx53.git;a=tree;h=a0b5ec7ae344797935a578e195ac8927a68c3671;hb=HEAD Well, you're one click from the Makefile which starts with the kernel version encoded: http://android.git.linaro.org/gitweb?p=kernel/imx53.git;a=blob;f=Makefile;h=c44d720b88f0d8ac42b5b25c076ae605cb273263;hb=HEAD Thanks for your support BR Tugrul -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Wanted: superstar hacker to complete Mono port to armhf
Hello Jo, I am forwarding the message to a couple mailing lists which might have people interested on the Mono porting for ARM hard-float ABI. 2012/2/2 Jo Shields direct...@apebox.org: Right now, Mono is available in Debian armhf. This is a hack - what we're actually doing is building Mono as an armhf binary, but built to emit soft VFP instructions and using calling conventions and ABI for armel. This hack works well enough for pure cross-platform code (like the C# compiler) to run, but dies in a heap for anything complex. This situation is a bit on the crappy side of crap. In order for Mono on armhf not to be a waste of time, a true port needs to be completed. If I were to make a not-remotely-educated guess, I'd say it needs about 550 lines of changes, primarily the addition of code to emit the correct instructions feeling the correct registers in mono/mini/mini-arm.c plus a couple of tweaks to related headers. Upstream have also indicated that they're happy to provide guidance and pointers on how to implement this port, although they're unable to provide the requisite code themselves. Sadly, unless someone in the community is able to step forward and contribute here, it's only a matter of time before the armhf packages are rightfully marked RC-buggy, and 100+ packages need to be axed from armhf. This would make me sad. -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Wanted: superstar hacker to complete Mono port to armhf
On Fri, 2012-02-03 at 00:15 +0100, Alexander Graf wrote: On 03.02.2012, at 00:11, Hector Oron wrote: Hello Jo, I am forwarding the message to a couple mailing lists which might have people interested on the Mono porting for ARM hard-float ABI. 2012/2/2 Jo Shields direct...@apebox.org: Right now, Mono is available in Debian armhf. This is a hack - what we're actually doing is building Mono as an armhf binary, but built to emit soft VFP instructions and using calling conventions and ABI for armel. This hack works well enough for pure cross-platform code (like the C# compiler) to run, but dies in a heap for anything complex. This situation is a bit on the crappy side of crap. In order for Mono on armhf not to be a waste of time, a true port needs to be completed. If I were to make a not-remotely-educated guess, I'd say it needs about 550 lines of changes, primarily the addition of code to emit the correct instructions feeling the correct registers in mono/mini/mini-arm.c plus a couple of tweaks to related headers. Upstream have also indicated that they're happy to provide guidance and pointers on how to implement this port, although they're unable to provide the requisite code themselves. Sadly, unless someone in the community is able to step forward and contribute here, it's only a matter of time before the armhf packages are rightfully marked RC-buggy, and 100+ packages need to be axed from armhf. This would make me sad. Please check our mono arm patches in OBS: https://build.opensuse.org/package/files?package=mono-coreproject=openSUSE%3AFactory%3AARM While slightly hacky, they enable full armhf support for arm. At least for us it's worked pretty well. Mono is a rather core dependency of a lot of stuff. Are these really giving you everything you need for openSUSE w/ hardfloat? They don't really seem very different from what we're doing in Debian, i.e. using the existing VFP softfloat code signature.asc Description: This is a digitally signed message part ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH v7 4/4] EXYNOS: SMDK5250: Add MMC SPL support
On Thursday 02 February 2012 04:11:27 Chander Kashyap wrote:
--- /dev/null
+++ b/board/samsung/smdk5250/tools/mkexynos_image.c
tools should be in tools/. there are already plenty of examples in there (see
tools/msxboot.c as the first example i found by reading tools/Makefile).
+int main(int argc, char **argv)
+{
...
+ unsigned char buffer[BUFSIZE] = {0};
this is an implicit memset() and from what i can see in the code, useless.
you read() the entire buffer, so there's no need to initialize it.
+ if (argc != 3) {
+ printf( %d Wrong number of arguments\n, argc);
this should tell the user how to use the tool.
fprintf(stderr, Usage: %s infile outfile\n, argv[0]);
+ if (ifd)
+ close(ifd);
this if() is wrong (0 is a valid fd) and useless (you already abort if ifd did
not succeed). just delete the if statement.
+ len = lseek(ifd, 0, SEEK_END);
+ lseek(ifd, 0, SEEK_SET);
lazy man's stat() :P. just use stat(). and change the type of len to
off_t.
+ count = (len CHECKSUM_OFFSET) ? len : CHECKSUM_OFFSET;
+
+ if (read(ifd, buffer, count) != count) {
count should be a ssize_t. although, this doesn't handle partial interrupted
reads, so i wonder if this could shouldn't just be changed to use stdio
fopen/fread. probably would be simpler that way too.
+ if (ifd)
+ close(ifd);
+ if (ofd)
+ close(ofd);
these if checks are wrong for the same reason mentioned above
+ unsigned long checksum = 0;
...
+ for (i = 0, checksum = 0; i CHECKSUM_OFFSET; i++)
+ checksum += buffer[i];
+ memcpy(buffer[CHECKSUM_OFFSET], checksum, sizeof(checksum));
pretty sure this fails if this tool is run on a big-endian machine, as well as
64bit vs 32bit. change the type of checksum to uint32_t, then use something
like:
put_unaligned_le32(checksum, buffer[CHECKSUM_OFFSET]);
+ if (write(ofd, buffer, BUFSIZE) != BUFSIZE) {
same issues as the read() mentioned above
+ if (ifd)
+ close(ifd);
+ if (ofd)
+ close(ofd);
same bad if() logic
+ if (ifd)
+ close(ifd);
+ if (ofd)
+ close(ofd);
same bad if() logic
-mike
signature.asc
Description: This is a digitally signed message part.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Wanted: superstar hacker to complete Mono port to armhf
On 03.02.2012, at 00:11, Hector Oron wrote: Hello Jo, I am forwarding the message to a couple mailing lists which might have people interested on the Mono porting for ARM hard-float ABI. 2012/2/2 Jo Shields direct...@apebox.org: Right now, Mono is available in Debian armhf. This is a hack - what we're actually doing is building Mono as an armhf binary, but built to emit soft VFP instructions and using calling conventions and ABI for armel. This hack works well enough for pure cross-platform code (like the C# compiler) to run, but dies in a heap for anything complex. This situation is a bit on the crappy side of crap. In order for Mono on armhf not to be a waste of time, a true port needs to be completed. If I were to make a not-remotely-educated guess, I'd say it needs about 550 lines of changes, primarily the addition of code to emit the correct instructions feeling the correct registers in mono/mini/mini-arm.c plus a couple of tweaks to related headers. Upstream have also indicated that they're happy to provide guidance and pointers on how to implement this port, although they're unable to provide the requisite code themselves. Sadly, unless someone in the community is able to step forward and contribute here, it's only a matter of time before the armhf packages are rightfully marked RC-buggy, and 100+ packages need to be axed from armhf. This would make me sad. Please check our mono arm patches in OBS: https://build.opensuse.org/package/files?package=mono-coreproject=openSUSE%3AFactory%3AARM While slightly hacky, they enable full armhf support for arm. At least for us it's worked pretty well. Mono is a rather core dependency of a lot of stuff. Alex ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
