Re: [U-Boot] [PATCH 2/2] arm/km: fix u-boot.kwb build breakage
> -Original Message- > From: Holger Brunck [mailto:holger.bru...@keymile.com] > Sent: Tuesday, June 14, 2011 12:42 PM > To: u-boot@lists.denx.de > Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar; Heiko Schocher > Subject: [PATCH 2/2] arm/km: fix u-boot.kwb build breakage > > commit 010a958b > (arm/km: remove CONFIG_SYS_KWD_CONFIG from keymile-common.h) > breaks building keymile arm targets, when u-boot.kwb tries to > generate the binary with mkimage. A simple make or MAKEALL > succeeded because it don't try to build the kirwood binary at the end. > > Due this commit we use the CONFIG_SYS_KWD_CONFIG from the > arch-kirkwood/config.h and it was removed from the board config. > But it was forgotten to include the header. Now the header is included > in km_arm.h. Some other defines were obsolete due to this include, > these are also removed in this commit. > > Signed-off-by: Holger Brunck > cc: Valentin Longchamp > cc: Prafulla Wadaskar > cc: Heiko Schocher > --- > include/configs/km/km_arm.h | 30 +++--- > include/configs/mgcoge3un.h |1 + > 2 files changed, 8 insertions(+), 23 deletions(-) > > diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h > index 20ee6ea..29815be 100644 > --- a/include/configs/km/km_arm.h > +++ b/include/configs/km/km_arm.h > @@ -40,15 +40,20 @@ > * High Level Configuration Options (easy to change) > */ > #define CONFIG_MARVELL > -#define CONFIG_ARM926EJS /* Basic Architecture */ > #define CONFIG_FEROCEON_88FR131 /* CPU Core subversion */ > #define CONFIG_KIRKWOOD /* SOC Family Name */ > -#define CONFIG_KW88F6281 /* SOC Name */ > #define CONFIG_MACH_KM_KIRKWOOD /* Machine type */ > > /* include common defines/options for all Keymile boards */ > #include "keymile-common.h" > > +#define CONFIG_KW88F6281 /* SOC Name */ Why did you moved this from top to here? > +#define CONFIG_CMD_NAND > +#define CONFIG_CMD_SF I think CONFIG_CMD_XXX should ideally below #include and that too in .h file. Rest Ack of the patch Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] arm/kirkwood: if CONFIG_SOFT_I2C is set don't set CONFIG_I2C_MVTWSI
> -Original Message- > From: Holger Brunck [mailto:holger.bru...@keymile.com] > Sent: Tuesday, June 14, 2011 12:42 PM > To: u-boot@lists.denx.de > Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar; Heiko Schocher > Subject: [PATCH 1/2] arm/kirkwood: if CONFIG_SOFT_I2C is set don't set > CONFIG_I2C_MVTWSI > > Some boards e.g. keymile arm boards have CONFIG_CMD_I2C switched on > but they use soft i2c on kirkwood. So don't switch CONFIG_I2C_MVTWSI > on in this case. > > Signed-off-by: Holger Brunck > cc: Valentin Longchamp > cc: Prafulla Wadaskar > cc: Heiko Schocher > --- > arch/arm/include/asm/arch-kirkwood/config.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/include/asm/arch-kirkwood/config.h > b/arch/arm/include/asm/arch-kirkwood/config.h > index 71ba464..b7dae1e 100644 > --- a/arch/arm/include/asm/arch-kirkwood/config.h > +++ b/arch/arm/include/asm/arch-kirkwood/config.h > @@ -137,7 +137,9 @@ > * I2C related stuff > */ > #ifdef CONFIG_CMD_I2C > +#ifndef CONFIG_SOFT_I2C > #define CONFIG_I2C_MVTWSI > +#endif > #define CONFIG_SYS_I2C_SLAVE 0x0 > #define CONFIG_SYS_I2C_SPEED 10 > #endif Acked-By: Prafulla Wadaskar Regards.. Prafulla . . > -- > 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm/km: fix u-boot.kwb build breakage
Hi Prafulla, On 06/15/2011 09:18 AM, Prafulla Wadaskar wrote: > > >> -Original Message- >> From: Holger Brunck [mailto:holger.bru...@keymile.com] >> Sent: Tuesday, June 14, 2011 12:42 PM >> To: u-boot@lists.denx.de >> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar; Heiko Schocher >> Subject: [PATCH 2/2] arm/km: fix u-boot.kwb build breakage >> >> commit 010a958b >> (arm/km: remove CONFIG_SYS_KWD_CONFIG from keymile-common.h) >> breaks building keymile arm targets, when u-boot.kwb tries to >> generate the binary with mkimage. A simple make or MAKEALL >> succeeded because it don't try to build the kirwood binary at the end. >> >> Due this commit we use the CONFIG_SYS_KWD_CONFIG from the >> arch-kirkwood/config.h and it was removed from the board config. >> But it was forgotten to include the header. Now the header is included >> in km_arm.h. Some other defines were obsolete due to this include, >> these are also removed in this commit. >> >> Signed-off-by: Holger Brunck >> cc: Valentin Longchamp >> cc: Prafulla Wadaskar >> cc: Heiko Schocher >> --- >> include/configs/km/km_arm.h | 30 +++--- >> include/configs/mgcoge3un.h |1 + >> 2 files changed, 8 insertions(+), 23 deletions(-) >> >> diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h >> index 20ee6ea..29815be 100644 >> --- a/include/configs/km/km_arm.h >> +++ b/include/configs/km/km_arm.h >> @@ -40,15 +40,20 @@ >> * High Level Configuration Options (easy to change) >> */ >> #define CONFIG_MARVELL >> -#define CONFIG_ARM926EJS/* Basic Architecture */ >> #define CONFIG_FEROCEON_88FR131 /* CPU Core subversion */ >> #define CONFIG_KIRKWOOD /* SOC Family Name */ >> -#define CONFIG_KW88F6281/* SOC Name */ >> #define CONFIG_MACH_KM_KIRKWOOD /* Machine type */ >> >> /* include common defines/options for all Keymile boards */ >> #include "keymile-common.h" >> >> +#define CONFIG_KW88F6281/* SOC Name */ > > Why did you moved this from top to here? > Indeed this is unneeded. I fix this and resubmit. >> +#define CONFIG_CMD_NAND >> +#define CONFIG_CMD_SF > > I think CONFIG_CMD_XXX should ideally below #include > and that too in .h file. > I agree for a single board support, but this is not possible in our approach. We include config_cmd_default.h in keymile-common.h. And keymile-common.h is valid for our powerpc and arm boards. In km_arm.h we add the CMD settings which are only additionaly needed on our arm boards. > Rest Ack of the patch > Ok. Best regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP3 clocks initialization not consistent with x-loader?
Hi,
x-loader has the following comment and if statement for all boards supporting
omap36xx SoC:
--cut
/*
* On OMAP3630, DDR data corruption has been observed on OFF mode
* exit if the sys clock was lower than 26M. As a work around,
* OMAP3630 is operated at 26M sys clock and this internal division
* is not performed.
*/
if((is_cpu_family() != CPU_OMAP36XX) && (sys_clkin_sel > 2)) {
sr32(PRM_CLKSRC_CTRL, 6, 2, 2);/* input clock divider */
clk_index = sys_clkin_sel/2;
} else {
sr32(PRM_CLKSRC_CTRL, 6, 2, 1);/* input clock divider */
clk_index = sys_clkin_sel;
}
--cut
U-Boot's omap3 clock initialization does not have that check for omap36xx.
Shouldn't we have it also in U-Boot to workaround that DDR data corruption
issue?
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] arm/km: fix u-boot.kwb build breakage
commit 010a958b (arm/km: remove CONFIG_SYS_KWD_CONFIG from keymile-common.h) breaks building keymile arm targets, when u-boot.kwb tries to generate the binary with mkimage. A simple make or MAKEALL succeeded because it don't try to build the kirwood binary at the end. Due this commit we use the CONFIG_SYS_KWD_CONFIG from the arch-kirkwood/config.h and it was removed from the board config. But it was forgotten to include the header. Now the header is included in km_arm.h. Some other defines were obsolete due to this include, these are also removed in this commit. Signed-off-by: Holger Brunck cc: Valentin Longchamp cc: Prafulla Wadaskar cc: Heiko Schocher --- changes for v2: - move CONFIG_KW88F6281 to original place, it was unneeded to touch this for the initial patch include/configs/km/km_arm.h | 28 ++-- include/configs/mgcoge3un.h |1 + 2 files changed, 7 insertions(+), 22 deletions(-) diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h index 20ee6ea..4741278 100644 --- a/include/configs/km/km_arm.h +++ b/include/configs/km/km_arm.h @@ -40,7 +40,6 @@ * High Level Configuration Options (easy to change) */ #define CONFIG_MARVELL -#define CONFIG_ARM926EJS /* Basic Architecture */ #define CONFIG_FEROCEON_88FR131/* CPU Core subversion */ #define CONFIG_KIRKWOOD/* SOC Family Name */ #define CONFIG_KW88F6281 /* SOC Name */ @@ -49,6 +48,12 @@ /* include common defines/options for all Keymile boards */ #include "keymile-common.h" +#define CONFIG_CMD_NAND +#define CONFIG_CMD_SF +#define CONFIG_SOFT_I2C/* I2C bit-banged */ + +#include "asm/arch/config.h" + #define CONFIG_SYS_TEXT_BASE 0x0400 /* code address after reloc */ #define CONFIG_ENV_SIZE(128 << 10) /* NAND chip block size */ #define CONFIG_SYS_MEMTEST_START 0x0040/* 4M */ @@ -75,12 +80,7 @@ #define CONFIG_KM_ARCH_DBG_FILE"scripts/debug-arm-env.txt" -#define CONFIG_MD5 /* get_random_hex on krikwood needs MD5 support */ #define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */ -#define CONFIG_KIRKWOOD_EGIGA_INIT /* Enable GbePort0/1 for kernel */ -#undef CONFIG_KIRKWOOD_PCIE_INIT /* Disable PCIE Port0 for kernel */ -#define CONFIG_KIRKWOOD_RGMII_PAD_1V8 /* Set RGMII Pad voltage to 1.8V */ - #define CONFIG_MISC_INIT_R /* @@ -116,7 +116,6 @@ */ #define CONFIG_CMD_ELF #define CONFIG_CMD_MTDPARTS -#define CONFIG_CMD_NAND #define CONFIG_CMD_NFS /* @@ -131,8 +130,6 @@ */ #define CONFIG_SYS_MAX_NAND_DEVICE 1 #define NAND_MAX_CHIPS 1 -#define CONFIG_NAND_KIRKWOOD -#define CONFIG_SYS_NAND_BASE 0xd800 #define BOOTFLASH_START0x0 @@ -175,8 +172,6 @@ /* * I2C related stuff */ -#defineCONFIG_SOFT_I2C /* I2C bit-banged */ - #defineCONFIG_KIRKWOOD_GPIO/* Enable GPIO Support */ #if defined(CONFIG_SOFT_I2C) #ifndef __ASSEMBLY__ @@ -200,8 +195,6 @@ int get_scl(void); #define I2C_DELAY udelay(3) /* 1/4 I2C clock duration */ #define I2C_SOFT_DECLARATIONS -#defineCONFIG_SYS_I2C_SLAVE0x0 -#defineCONFIG_SYS_I2C_SPEED10 #endif #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50 @@ -224,15 +217,8 @@ int get_scl(void); #define CONFIG_ENV_OFFSET_REDUND 0x2000 /* no bracets! */ #define CONFIG_ENV_SIZE_REDUND (CONFIG_ENV_SIZE) -#define CONFIG_CMD_SF - #define CONFIG_SPI_FLASH -#define CONFIG_HARD_SPI -#define CONFIG_KIRKWOOD_SPI #define CONFIG_SPI_FLASH_STMICRO -#define CONFIG_ENV_SPI_BUS 0 -#define CONFIG_ENV_SPI_CS 0 -#define CONFIG_ENV_SPI_MAX_HZ 5000/* 50Mhz */ #define FLASH_GPIO_PIN 0x0001 @@ -272,8 +258,6 @@ int get_scl(void); /* additions for new relocation code, must be added to all boards */ #define CONFIG_SYS_SDRAM_BASE 0x -/* Kirkwood has 2k of Security SRAM, use it for SP */ -#define CONFIG_SYS_INIT_SP_ADDR0xC8012000 /* Do early setups now in board_init_f() */ #define CONFIG_BOARD_EARLY_INIT_F diff --git a/include/configs/mgcoge3un.h b/include/configs/mgcoge3un.h index 6d56d7d..8d1b61f 100644 --- a/include/configs/mgcoge3un.h +++ b/include/configs/mgcoge3un.h @@ -48,6 +48,7 @@ #define KM_ENV_BUS "pca9547:70:d" /* I2C2 (Mux-Port 5)*/ /* we use a new RAM type on mgcoge3un board */ +#undef CONFIG_SYS_KWD_CONFIG #define CONFIG_SYS_KWD_CONFIG $(SRCTREE)/$(CONFIG_BOARDDIR)/kwbimage-memphis.cfg /* -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] arm/kirkwood: if CONFIG_SOFT_I2C is set don't set CONFIG_I2C_MVTWSI
Some boards e.g. keymile arm boards have CONFIG_CMD_I2C switched on but they use soft i2c on kirkwood. So don't switch CONFIG_I2C_MVTWSI on in this case. Signed-off-by: Holger Brunck cc: Valentin Longchamp cc: Prafulla Wadaskar cc: Heiko Schocher --- changes for v2: - nothing arch/arm/include/asm/arch-kirkwood/config.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-kirkwood/config.h b/arch/arm/include/asm/arch-kirkwood/config.h index 71ba464..b7dae1e 100644 --- a/arch/arm/include/asm/arch-kirkwood/config.h +++ b/arch/arm/include/asm/arch-kirkwood/config.h @@ -137,7 +137,9 @@ * I2C related stuff */ #ifdef CONFIG_CMD_I2C +#ifndef CONFIG_SOFT_I2C #define CONFIG_I2C_MVTWSI +#endif #define CONFIG_SYS_I2C_SLAVE 0x0 #define CONFIG_SYS_I2C_SPEED 10 #endif -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: sdhci: rework Samsung specfic code
Tested-by: Jaehoon Chung But Mr.Kang mentioned missing arch/arm/include/asm/arch-s5pc1xx/cpu.h Need the below patch.. (s5pc2xx and s5pc1xx are working well) diff --git a/arch/arm/include/asm/arch-s5pc1xx/cpu.h b/arch/arm/include/asm/arch-s5pc1xx/cpu.h index e74959f..86b7bd2 100644 --- a/arch/arm/include/asm/arch-s5pc1xx/cpu.h +++ b/arch/arm/include/asm/arch-s5pc1xx/cpu.h @@ -94,6 +94,9 @@ SAMSUNG_BASE(mmc, MMC_BASE) SAMSUNG_BASE(sromc, SROMC_BASE) SAMSUNG_BASE(timer, PWMTIMER_BASE) SAMSUNG_BASE(uart, UART_BASE) + +#define samsung_get_base_mmc_offset(idx) (samsung_get_base_mmc() + \ +0x1 * (idx)) #endif #endif /* _S5PC1XX_CPU_H */ Regards, Jaehoon Chung Minkyu Kang wrote: > Dear Rob Herring, > > On 14 June 2011 23:48, Rob Herring wrote: >> arch/arm/include/asm/arch-s5pc1xx/mmc.h | 73 >> -- >> arch/arm/include/asm/arch-s5pc2xx/cpu.h |4 ++ >> arch/arm/include/asm/arch-s5pc2xx/mmc.h | 73 >> -- >> board/samsung/goni/goni.c|4 +- >> board/samsung/universal_c210/universal.c |6 +- >> drivers/mmc/sdhci.c | 31 +++-- >> include/sdhci.h | 62 + >> 7 files changed, 88 insertions(+), 165 deletions(-) >> delete mode 100644 arch/arm/include/asm/arch-s5pc1xx/mmc.h >> delete mode 100644 arch/arm/include/asm/arch-s5pc2xx/mmc.h >> create mode 100644 include/sdhci.h >> >> --- a/arch/arm/include/asm/arch-s5pc2xx/cpu.h >> +++ b/arch/arm/include/asm/arch-s5pc2xx/cpu.h >> @@ -108,6 +108,10 @@ SAMSUNG_BASE(uart, UART_BASE) >> SAMSUNG_BASE(usb_phy, USBPHY_BASE) >> SAMSUNG_BASE(usb_otg, USBOTG_BASE) >> SAMSUNG_BASE(watchdog, WATCHDOG_BASE) >> + >> +#define samsung_get_base_mmc_offset(idx) (samsung_get_base_mmc() + \ >> +0x1 * (idx)) >> + >> #endif >> >> #endif /* _S5PC2XX_CPU_H */ > > Looks fine. > But, missing arch/arm/include/asm/arch-s5pc1xx/cpu.h > > Dear Jaehoon, > > Please test this patch on s5pc1xx and s5pc2xx. > > Thanks > Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: sdhci: rework Samsung specfic code
On 15 June 2011 17:12, Jaehoon Chung wrote: > Tested-by: Jaehoon Chung > > But Mr.Kang mentioned missing arch/arm/include/asm/arch-s5pc1xx/cpu.h > Need the below patch.. > (s5pc2xx and s5pc1xx are working well) > > diff --git a/arch/arm/include/asm/arch-s5pc1xx/cpu.h > b/arch/arm/include/asm/arch-s5pc1xx/cpu.h > index e74959f..86b7bd2 100644 > --- a/arch/arm/include/asm/arch-s5pc1xx/cpu.h > +++ b/arch/arm/include/asm/arch-s5pc1xx/cpu.h > @@ -94,6 +94,9 @@ SAMSUNG_BASE(mmc, MMC_BASE) > SAMSUNG_BASE(sromc, SROMC_BASE) > SAMSUNG_BASE(timer, PWMTIMER_BASE) > SAMSUNG_BASE(uart, UART_BASE) > + > +#define samsung_get_base_mmc_offset(idx) (samsung_get_base_mmc() + \ > + 0x1 * (idx)) I think.. offset is wrong. In case of s5pc1xx, 0x10_ is right. Please check. Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: sdhci: rework Samsung specfic code
Minkyu Kang wrote: > On 15 June 2011 17:12, Jaehoon Chung wrote: >> Tested-by: Jaehoon Chung >> >> But Mr.Kang mentioned missing arch/arm/include/asm/arch-s5pc1xx/cpu.h >> Need the below patch.. >> (s5pc2xx and s5pc1xx are working well) >> >> diff --git a/arch/arm/include/asm/arch-s5pc1xx/cpu.h >> b/arch/arm/include/asm/arch-s5pc1xx/cpu.h >> index e74959f..86b7bd2 100644 >> --- a/arch/arm/include/asm/arch-s5pc1xx/cpu.h >> +++ b/arch/arm/include/asm/arch-s5pc1xx/cpu.h >> @@ -94,6 +94,9 @@ SAMSUNG_BASE(mmc, MMC_BASE) >> SAMSUNG_BASE(sromc, SROMC_BASE) >> SAMSUNG_BASE(timer, PWMTIMER_BASE) >> SAMSUNG_BASE(uart, UART_BASE) >> + >> +#define samsung_get_base_mmc_offset(idx) (samsung_get_base_mmc() + \ >> +0x1 * (idx)) > > I think.. offset is wrong. > In case of s5pc1xx, 0x10_ is right. > Please check. Sorry..my mistake..you're right. Offset is 0x10_ Thanks, Jaehoon chung ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Dear Wolfgang, On Tuesday 14 June 2011 07:23 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4df7488a.6000...@ti.com> you wrote: >> >> Yes. I have seen those macros. But more often than not the bit field is >> more than 1 bit wide and the value to be set is not necessarily all 0's >> or all 1's. That's why I have to use clrsetbits_*() > > I see. In such a case (and only then) clrsetbits_*() is indeed the > right choice. > >> The problem I have to deal with is different. get_bit_field() was >> intended to extract bit fields from an integer. So, the target usage >> will be something like this(where a, b, and c are bit fields in >> register my_reg) >> >> u32 my_reg, a_val, b_val, c_val; >> >> u32 my_reg = readl(my_reg_addr); >> >> a_val = get_bit_field(my_reg, a_mask); >> b_val = get_bit_field(my_reg, b_mask); >> c_val = get_bit_field(my_reg, c_mask); >> >> Do you see an alternative method for doing this using the standard >> macros? > > Please see the example given here: > > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/101146 > > Looking closer, the "FIELD_VAL" macro alone will probably not suffice, > as you need both shift directions, like that: > > #define FIELD_SHIFT 16 > #define FIELD_MASK 0xF When I said mask I meant the 'shifted mask' like: #define FIELD_MASK (0xF << 16) So, the shift information is embedded in this mask and can be extracted by finding the first set bit. But in reality my get_bit_field() function indeed takes both arguments. So it's something like this: #define get_bit_field(x, shift, mask)\ (((x) & (mask)) >> (shift)) #define A_SHIFT 16 #define A_MASK (0xF << 16) and then use it like: a_val = get_bit_field(my_reg, A_SHIFT, A_MASK); > > #define FIELD_BITS(x) (x<< 16) > #define FIELD_MASK FIELD_BITS(0xF) > #define FIELD_VAL(x) ((x& FIELD_MASK)>> 16) > > The code would then look something like this: > > my_reg = readl(my_reg_addr); > > a_val = A_VAL(my_reg); > b_val = B_VAL(my_reg); > c_val = C_VAL(my_reg); If I have to do something like this I will have to now generate macros like A_VAL(x) for hundreds of fields. Is it really necessary when the following will do the job for me with the existing infrastructure I have: a_val = get_bit_field(my_reg, A_SHIFT, A_MASK); b_val = get_bit_field(my_reg, B_SHIFT, B_MASK); Please note that in this case I don't have an alternative with standard macros. If this is not possible I would rather prefer to keep it simple like this: a_val = (my_reg & A_MASK) >> A_SHIFT; best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3/devkit8000 division/multiplication function problems
Hi Graeme,
Setting r8 to gd was the solution. I now set it right before the first
access to gd then it works like a charm:
asm("ldr r8, [%[value]]"::[value] "r" (&gd):"r8"); /* Set r8 to gd */
Thanks for your help!
Simon
2011/6/14 Simon Schwarz :
> Ok. It seems I (or more precise a college) have a possible solution.
>
> From the assembly one can see that r8 is used with a total ridiculus
> value - and on ARM r8 is used to point to gd - tada.
>
> I will test that and report back.
>
> Regards
> Simon
>
> 2011/6/14 Simon Schwarz :
>> Hi again,
>>
>> seems that there is a problem with gd - at least your test breaks...
>>
>> I added unsigned long temp at the end of gd.
>>
>> And added
>> unsigned long a=0;
>> a=gd->temp;
>> gd->temp = 4;
>>
>> to calc_divisor
>>
>> Here is a part of the debugging session:
>> Breakpoint 1, calc_divisor (port=) at serial.c:171
>> 171 a = gd->temp;
>> (gdb) p/x a
>> $1 = 0x0
>> (gdb) s
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0x00014010 in ?? ()
>>
>> had to use Strg+C to get back a gdb prompt.
>>
>> But if do: p *gd
>> The output seems to be ok (for this stage of the SPL):
>> $3 = {bd = 0x40203df0, flags = 1, baudrate = 115200, have_console = 0,
>> env_addr = 0, env_valid = 0, fb_base = 0, timer_rate_hz = 0, tbl = 0,
>> tbu = 0, timer_reset_value = 0, lastinc = 0, relocaddr = 0, ram_size =
>> 0, mon_len = 0, irq_sp = 0, start_addr_sp = 0, reloc_off = 0, tlb_addr
>> = 0, jt = 0x0, env_buf = '\000' , temp = 0}
>>
>> Ideas? A Problem with the linker script maybe?
>>
>> Regards
>> Simon
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Release delayed by two weeks
Dear Albert, In message <4df853c3.9080...@discworld.dascon.de> Michael Schwingen wrote: > > what about the IXP patches? > > Marek sent a pull request on 2011-05-27, but I can't find them in a > freshly pulled master. Could you please comment? Thanks! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Imitation is the sincerest form of plagarism. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Dear Aneesh V, In message <4df871e3.8080...@ti.com> you wrote: > > So, the shift information is embedded in this mask and can be extracted > by finding the first set bit. But in reality my get_bit_field() > function indeed takes both arguments. So it's something like this: As stated before, I will not accept any bit filed macros like get_bit_field(). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Far back in the mists of ancient time, in the great and glorious days of the former Galactic Empire, life was wild, rich and largely tax free. - Douglas Adams, _The Hitchhiker's Guide to the Galaxy_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Albert, please pull from u-boot-imx. There are only fix for a couple of still broken boards. The following changes since commit 9571865e0d32b1bcf8a6625497d1cd5d4bbad354: Merge branch 'master' of git://git.denx.de/u-boot-arm (2011-06-08 23:29:04 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Fabio Estevam (2): mx1ads: Fix build by using new relocation scheme imx31_phycore: Fix build by using new relocation scheme Stefano Babic (1): MX31: QONG: drop config.mk board/davedenx/qong/config.mk |3 --- board/imx31_phycore/config.mk |1 - board/imx31_phycore/imx31_phycore.c | 20 +--- board/mx1ads/config.mk | 25 - board/mx1ads/mx1ads.c | 27 +++ include/configs/imx31_phycore.h | 12 include/configs/mx1ads.h| 10 ++ include/configs/qong.h |4 +++- 8 files changed, 57 insertions(+), 45 deletions(-) delete mode 100644 board/davedenx/qong/config.mk delete mode 100644 board/imx31_phycore/config.mk delete mode 100644 board/mx1ads/config.mk Thanks, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/22] omap4: add spl support for OMAP4 SDP
Dear Aneesh V, In message <4dde54e5.7080...@ti.com> you wrote: > > >> And how do you distinguish between the two cases at the top level > >> Makefile? Using a CONFIG flag or on a per platform basis? > > > > The decision should not be make in the top level makefile, but in > > spl/Makefile. And this can simply check if a board directory exists > > in the first place. > > 1. How about the case where there is some board dependent code but also > code shared by the boards(SoC based code). Will we have different > 'Makefile's then - one for board and one for SoC. Will we then build > different libraries at each leavel and link them together etc? Yes. If a board directory exists the code there gets built and then linked. > 2. I think one key thing that you are perhaps missing is that in SPL > the board level Makefile is not just meant for board level files. This probably should be reworked. We should have a Makefile in nand_spl/ which covers the general code and then runs the respective SoC and/or board specific sub-makes. > Instead it is used to pull together files from all the layers and make > a custom image. IMHO, we will get into un-necessary complexities if we Yes, but most of thisis actually not board specific, but more SoC specific, if not general at all. > lose this property of SPL. We may rather spend efforts on making the > regular U-Boot more configurable. Indeed we should allow for more fine granular selection. > The board level Makefile needs to have all the files. For the SoC level No. It needs only those files that are actually board specific. > selection of files and the SoC level rules, include the respective *.mk > files. Because in this case there are no board specific files there is I don;t think that this is actually board specific - if we follow that route, we will duplicate the same stuff for all boards that use the same SoC. > nothing more in the Makefile. Please note that this may not be the case > in general. Most boards, I suspect, may have some board specific files > too. That's why I suggest to separate common, SoC specific and board specific stuff . Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There were meetings. There were always meetings. And they were dull, which is part of the reason they were meetings. Dull likes company. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/22] omap: add spl support
Dear Aneesh V, In message <4dde5afe.9000...@ti.com> you wrote: > > I do not have any issue in having media specific files in their > respective directories. However, I would like to see the 'Makefile's > coming from the same directory tree irrespective of the media. So, how > about something like this: > > spl/ > mmc/ > nand/ > one-nand/ > board///Makefile Actually that would be board/[/]/ > The idea is to have the board level Makefile in 'spl/board/ > //' no matter what the SPL type is. This will help in better > consolidation of SPLs. OK. > I see 3 SPL use-cases in general: > 1. A single SPL that supports multiple media(suitable for SoCs with > large internal RAM) > 2. A single SPL supporting a single media(the board supports only one > media) 1. and 2. are actually the same (2. being the special case of N=1) > 3. Multiple SPLs for the same board each supporting a different > memory device(maybe preferred over 1 to keep the foot-print of each > small). > > Supporting (1) and (2) is straight forward with the above directory > structure. > > To support (3) the board level Makefile should conditionally > include the respective image file in the target 'all' based on CONFIG > options. For instance 'all' may include 'onenand-ipl-2k.bin' if > CONFIG_ONENAND_U_BOOT is defined and so on. I don't get this. Why don't we just pass the required make target from the top level Makefile? If we want to build "onenand-ipl-2k.bin" then this would result in running "make onenand-ipl-2k.bin" in the respective directory - this is then also independent of whether this image contains support for one specific boot device or for any set of different devices. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I object to intellect without discipline; I object to power without constructive purpose. -- Spock, "The Squire of Gothos", stardate 2124.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/10] armv7: replace CONFIG_L2_OFF with CONFIG_SYS_NO_L2CACHE
Dear Aneesh V, In message <4decbc5c.10...@ti.com> you wrote: > Hi Wolfgang, > > On Tuesday 17 May 2011 04:39 PM, Wolfgang Denk wrote: > > Dear Aneesh V, > > > > In message<4dd24715.4010...@ti.com> you wrote: > >> > >>> Please fix all these names. > >> > >> Ok. Including the existing CONFIG_SYS_NO_DCACHE and > >> CONFIG_SYS_NO_ICACHE too, right? > > > > yes, please. Thanks a lot! > > How about the existing flag CONFIG_SYS_NO_CP15_CACHE > > I think this flag should be simply removed. I think > CONFIG_SYS_ICACHE_OFF and CONFIG_SYS_DCACHE_OFF together can serve all > needs. Agreed. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Monday is an awful way to spend one seventh of your life. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 22/22] omap: spl: add more debug traces
Dear Aneesh V, In message <4df617c2.6070...@ti.com> you wrote: > > > Console should _always_ be enabled as early as possible, > > Unfortunately this is not the case with U-Boot today. Console > initialization happens in board_init_f(). Before board_init_f() > typically a lot of(in fact most of) low level initialization happens > through the lowlevel_init() function called from start.S and the > initial part of init_sequence() As the name LOWLEVEL_init() suggests, this is suppoed to contain always only the bare minimum of initialization that is necessary to get the CPU running. All more complex initializations should be delayed and only be run when we have a proper environment, including debug output on the console. > > Can we not rather change the code so both configurations behave the > > same? > > In SPL I had more flexibility, so I do a simplified init of console > right at the beginning of lowlevel_init(), so I can use debug prints in > lowlevel_init(). Some part of our lowlevel_init() that is executed in > SPL path may also be executed by U-Boot if it runs from NOR flash, but > in this case console wouldn't be ready. That's why I made the macro. I do not understand this. How can you have more flexibility in the more restricted environment? We definitely should unify this. > No. That wouldn't serve the purpose. I need two macros to distinguish > between the two cases. > 1. 'debug()' - can be used in all places at which console is guaranteed > to be initialized whether executed as part of U-Boot or SPL. > 2. 'spl_debug()' to be used at places where console is initialized for > SPL but not for U-Boot (eg. lowlevel_init()) - so emit no code for > U-Boot. You see - this distinction is becoming a mess. Let's get rid of this and use common code for both cases. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Very ugly or very beautiful women should be flattered on their understanding, and mediocre ones on their beauty. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Information regarding load address, execute address and image load address
Hi, I need one clarification regarding load address, entry point inside the Kernel image & the address to where we load the image. Assume, the image header is as below. Image Name: Linux-2.6.38-10700-g846a497 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2064396 Bytes = 2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK And I load the image using loadb to address 0x80008000. Will this work?. Because here Image->load_address == Load_address for u-boot. Now u-boot considers this as XIP Image and will not move os data which actually will be at 0x80008040 to 0x80008000 Please correct me if I am wrong I have attached the console output for reference. Thanks & regards Gururaja CON_SOLE#iminfo ## Checking Image at 80008000 ... Legacy image found Image Name: Linux-2.6.38-10700-g846a497 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2064396 Bytes = 2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK CON_SOLE #bootm 0x80008000 * kernel: cmdline image address = 0x80008000 Boot reached stage 1 ## Booting kernel from Legacy Image at 80008000 ... Boot reached stage 2 Boot reached stage 3 Image Name: Linux-2.6.38-10700-g846a497 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2064396 Bytes = 2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Boot reached stage 4 Boot reached stage 5 Boot reached stage 6 kernel data at 0x80008040, len = 0x001f800c (2064396) Boot reached stage 14 ## No init Ramdisk ramdisk start = 0x, ramdisk end = 0x XIP Kernel Image ... OK OK kernel loaded at 0x80008000, end = 0x802c Boot reached stage 7 images.os.start = 0x80008000, images.os.end = 0x8020004c images.os.load = 0x80008000, load_end = 0x802c Boot reached stage 8 Boot reached stage 15 ## Transferring control to Linux (at address 80008000) ... Starting kernel ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OpenRD Ultimate SATA & SD
Hi, I've been trying to get a version of u-boot for OpenRD Ultimate that is willing to boot from all of NAND, USB, SD and SATA, and find that SD & SATA is still not possible with -rc1 as packaged for Debian (and it seems that nothing in the subsequent work in the master git would help, but if people tell me that it does, I'll give that a try). SATA throws an error in ide_preinit in drivers/block/mvsata_ide.c, and having looked into it, the second call to mvsata_ide_initialize_port is what fails. This is with a SATA drive plugged into the on-board SATA port, and with nothing plugged into the eSATA port. If I #undef CONFIG_SYS_ATA_IDE1_OFFSET in include/configs/openrd.h then the second mvsata_ide_initialize_port call is disabled, and I can then boot from SATA, but I've not got an eSATA drive to test whether it would have worked if I had one plugged in. I note that there is still something a little odd going on, since the drive seems to get detected twice: Marvell>> ide reset Reset IDE: Bus 0: OK Bus 1: OK Device 0: Model: HITACHI HTS723216L9SA60 Firm: FC2ZC50B Ser#: 091005FC1220NCHXGPLG Type: Hard Disk Supports 48-bit addressing Capacity: 152627.8 MB = 149.0 GB (312581808 x 512) Device 1: Model: HITACHI HTS723216L9SA60 Firm: FC2ZC50B Ser#: 091005FC1220NCHXGPLG Type: Hard Disk Supports 48-bit addressing Capacity: 152627.8 MB = 149.0 GB (312581808 x 512) but it seems to work OK anyway. As for the SD -- it detects OK, but seems to be unable to read more than a small amount of data from the SD card, as seen here: Marvell>> mmc init SDHC found. Card desciption is: Manufacturer: 0x1e, OEM "AB" Product name: "USD ", revision 1.0 Serial number: 93331321 Manufacturing date: 8/2010 CRC:0x00, b0 = 0 mmc1 is available Marvell>> ext2ls mmc 0 1024 . 1024 .. 12288 lost+found 1433576 vmlinuz-2.6.32-5-kir at which point it hangs. If I take the same SD card, put it in an SD-to-USB adaptor and then access it via the USB, I can boot the kernel, whereas it just locks up when accessed as an SD, which also seems to point at it not being able to do more than a small read via SD. Any suggestions on how to diagnose what's going on here would be most welcome. I've tried pointing gdb at it, but it seems not to be doing breakpoints as I'd expect, so hints on how to get gdb working as well would be helpful (yes, I am rather new to this :-) Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgp01BPGKO0Gy.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/22] omap: add spl support
Dear Wolfgang, On Wednesday 15 June 2011 03:43 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4dde5afe.9000...@ti.com> you wrote: >> >> I do not have any issue in having media specific files in their >> respective directories. However, I would like to see the 'Makefile's >> coming from the same directory tree irrespective of the media. So, how >> about something like this: >> >> spl/ >> mmc/ >> nand/ >> one-nand/ >> board///Makefile > > Actually that would be > >board/[/]/ > >> The idea is to have the board level Makefile in 'spl/board/ >> //' no matter what the SPL type is. This will help in better >> consolidation of SPLs. > > OK. > >> I see 3 SPL use-cases in general: >> 1. A single SPL that supports multiple media(suitable for SoCs with >> large internal RAM) >> 2. A single SPL supporting a single media(the board supports only one >> media) > > 1. and 2. are actually the same (2. being the special case of N=1) > >> 3. Multiple SPLs for the same board each supporting a different >> memory device(maybe preferred over 1 to keep the foot-print of each >> small). >> >> Supporting (1) and (2) is straight forward with the above directory >> structure. >> >> To support (3) the board level Makefile should conditionally >> include the respective image file in the target 'all' based on CONFIG >> options. For instance 'all' may include 'onenand-ipl-2k.bin' if >> CONFIG_ONENAND_U_BOOT is defined and so on. > > I don't get this. Why don't we just pass the required make target > from the top level Makefile? If we want to build "onenand-ipl-2k.bin" > then this would result in running "make onenand-ipl-2k.bin" in the > respective directory - this is then also independent of whether this > image contains support for one specific boot device or for any set of > different devices. Then you will have to deal with many such images in the top-level Makefile(u-boot/Makefile). Instead why not have just one rule like the below in the top-level Makefile for all the different spl's: SPL:$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools $(MAKE) -C spl/board/$(BOARDDIR) all And leave the rest to the board level Makefiles Of course, this is assuming the existing Makefile structure. With the new Makefile structure you are suggesting this may not hold good. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Dear Wolfgang, On Wednesday 15 June 2011 02:50 PM, Wolfgang Denk wrote: > Dear Aneesh V, > > In message<4df871e3.8080...@ti.com> you wrote: >> >> So, the shift information is embedded in this mask and can be extracted >> by finding the first set bit. But in reality my get_bit_field() >> function indeed takes both arguments. So it's something like this: > > As stated before, I will not accept any bit filed macros like > get_bit_field(). Will you accept something like this? a_val = (reg & a_mask) >> a_shift; best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-Boot PATCH MX31:] mxc_spi.c: typo fixed
From: Helmut Raiger Signed-off-by: Helmut Raiger --- drivers/spi/mxc_spi.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c index f909e07..698e726 100644 --- a/drivers/spi/mxc_spi.c +++ b/drivers/spi/mxc_spi.c @@ -31,7 +31,7 @@ /* i.MX27 has a completely wrong register layout and register definitions in the * datasheet, the correct one is in the Freescale's Linux driver */ -#error "i.MX27 CSPI not supported due to drastic differences in register definisions" \ +#error "i.MX27 CSPI not supported due to drastic differences in register definitions" \ "See linux mxc_spi driver from Freescale for details." #elif defined(CONFIG_MX31) -- 1.7.4.4 -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31: Improve the handling of unidentified silicon version
Hi Stefano, On 6/15/2011 2:29 AM, Stefano Babic wrote: ... > > Why is the new output better as we have now ? You drop the output of > the srev register, and then we cannot get which strange silicon version > is running without patching the code. Let me try to explain the problem I see with the current silicon detection mechanism: On my board (srev=0x28), which is a TO2.0 silicon I get: CPU: Freescale i.MX31 rev 2.0 at 531 MHz.Reset cause: WDOG On Felix´s MX31ADS board (srev=0x20) (unknown chip version) he gets: CPU: Freescale i.MX31 rev 2.0 unknown at 531 MHz.Reset cause: WDOG Reading rev 2.0 on Felix´s case is misleading IMHO as we tend to think that we have a TO2.0 silicon on his board even though we get a "unknown" string. The reason of this is that we currently return the .v struct when the silicon version is detected and the srev version when it is not recognized. >> if (srev == mx31_cpu_type[i].srev) >> return mx31_cpu_type[i].v; >> >> -return srev | 0x8000; >> +return 0x8000; > > IMHO in the case the revision is not recognized, it is better to print > the value of the srev register, as it is done now. Yes, agreed, but we should print srev as an hex number instead of a string as done today If you agree I can implement the following logic: When the chip version is detected let´s just leave as it is today: CPU: Freescale i.MX31 rev 2.0 at 531 MHz.Reset cause: WDOG When the chip version is not valid, then we print: CPU: Freescale i.MX31 (unknown rev, srev=0x20) at 531 MHz.Reset cause: WDOG Please let me know what you think about this proposal. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Information regarding load address, execute address and image load address
Dear "Hebbar, Gururaja", In message you wrote: > >Image Name: Linux-2.6.38-10700-g846a497 >Image Type: ARM Linux Kernel Image (uncompressed) >Data Size:2064396 Bytes = 2 MiB >Load Address: 80008000 >Entry Point: 80008000 >Verifying Checksum ... OK > > And I load the image using loadb to address 0x80008000. > > Will this work?. Because here Image->load_address == Load_address for u-boot. This is supposed to break. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If God wanted me to touch my toes, he'd have put them on my knees. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/22] omap: add spl support
Dear Aneesh, In message <4df88f45.9090...@ti.com> you wrote: > > > I don't get this. Why don't we just pass the required make target > > from the top level Makefile? If we want to build "onenand-ipl-2k.bin" > > then this would result in running "make onenand-ipl-2k.bin" in the > > respective directory - this is then also independent of whether this > > image contains support for one specific boot device or for any set of > > different devices. > > Then you will have to deal with many such images in the top-level > Makefile(u-boot/Makefile). Instead why not have just one rule like the > below in the top-level Makefile for all the different spl's: > > > SPL:$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools > $(MAKE) -C spl/board/$(BOARDDIR) all > > And leave the rest to the board level Makefiles We just discussed that there are cases where there may be no board level Makefile be needed at all, because there is no board specific code to handle. Also, why would there be many such images? We might just want to use more reasonable names. We have "u-boot.bin", and this works fine for all boards, so why cannot we make it that "u-boot-nand.bin" works for all boards booting from NAND, and in general "u-boot-.bin" works for all boards booting from a boot device? Instead of "onenand-ipl-2k.bin", we would just have a generic "u-boot-onenand.bin" > Of course, this is assuming the existing Makefile structure. With the > new Makefile structure you are suggesting this may not hold good. Why not? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Wenn das dann in die Hose geht, nehme ich es auf meine Kappe. -- Rudi Völler, 15. Nov 2003 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Dear Aneesh V, In message <4df89102.9040...@ti.com> you wrote: > > Will you accept something like this? > > a_val = (reg & a_mask) >> a_shift; Yes, of course (that's what seems most natural to me). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31: Improve the handling of unidentified silicon version
Hi Fabio, On 15/06/11 21:50, Fabio Estevam wrote: > Hi Stefano, > > On 6/15/2011 2:29 AM, Stefano Babic wrote: > ... >> >> Why is the new output better as we have now ? You drop the output of >> the srev register, and then we cannot get which strange silicon version >> is running without patching the code. > > Let me try to explain the problem I see with the current silicon detection > mechanism: > > On my board (srev=0x28), which is a TO2.0 silicon I get: > > CPU: Freescale i.MX31 rev 2.0 at 531 MHz.Reset cause: WDOG > > On Felix´s MX31ADS board (srev=0x20) (unknown chip version) he gets: > > CPU: Freescale i.MX31 rev 2.0 unknown at 531 MHz.Reset cause: WDOG > > Reading rev 2.0 on Felix´s case is misleading IMHO as we tend to think that > we have a TO2.0 silicon on his board even though we get a "unknown" string. > > The reason of this is that we currently return the .v struct when the silicon > version is detected and the srev version when it is not recognized. Ouch >>> if (srev == mx31_cpu_type[i].srev) >>> return mx31_cpu_type[i].v; >>> >>> - return srev | 0x8000; >>> + return 0x8000; >> >> IMHO in the case the revision is not recognized, it is better to print >> the value of the srev register, as it is done now. > > Yes, agreed, but we should print srev as an hex number instead of a string as > done today > > If you agree I can implement the following logic: > > When the chip version is detected let´s just leave as it is today: > > CPU: Freescale i.MX31 rev 2.0 at 531 MHz.Reset cause: WDOG > > When the chip version is not valid, then we print: > > CPU: Freescale i.MX31 (unknown rev, srev=0x20) at 531 MHz.Reset cause: WDOG > > Please let me know what you think about this proposal. Does 'srev' have a more plain language description? or would somebody reading that instantly know what 'srev' meant? If the later, then this looks good. If the former, then you really should be saying "(unknown rev, SOC Silicon ID=0x20)" where 'SOC silicon ID' is a string taken directly from a data sheet or manual. There is nothing worse than trying to do a search on a debug message in a manual where the string does not even exist Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31: Improve the handling of unidentified silicon version
Dear Fabio Estevam, In message <4df89c84.7090...@freescale.com> you wrote: ... > CPU: Freescale i.MX31 rev 2.0 unknown at 531 MHz.Reset cause: WDOG ... > When the chip version is not valid, then we print: > > CPU: Freescale i.MX31 (unknown rev, srev=0x20) at 531 MHz.Reset cause: WDOG Compare to the current line above - which new information do you print? None. You just print it in a new format, and with more characters, i. e. with a worse SNR. > Please let me know what you think about this proposal. You received 3 messages from 3 different guys who told you all the same: just leave the code as is. Your proposed changes are not considered an improvement. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "How is this place run - is it an anarchy?" "No, I wouldn't say so; it is not that well organised..." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/22] omap: add spl support
Dear Wolfgang, On Wednesday 15 June 2011 05:34 PM, Wolfgang Denk wrote: > Dear Aneesh, > > In message<4df88f45.9090...@ti.com> you wrote: >> >>> I don't get this. Why don't we just pass the required make target >>> from the top level Makefile? If we want to build "onenand-ipl-2k.bin" >>> then this would result in running "make onenand-ipl-2k.bin" in the >>> respective directory - this is then also independent of whether this >>> image contains support for one specific boot device or for any set of >>> different devices. >> >> Then you will have to deal with many such images in the top-level >> Makefile(u-boot/Makefile). Instead why not have just one rule like the >> below in the top-level Makefile for all the different spl's: >> >> >> SPL:$(TIMESTAMP_FILE) $(VERSION_FILE) depend tools >> $(MAKE) -C spl/board/$(BOARDDIR) all >> >> And leave the rest to the board level Makefiles > > We just discussed that there are cases where there may be no board > level Makefile be needed at all, because there is no board specific > code to handle. > > Also, why would there be many such images? We might just want to use > more reasonable names. We have "u-boot.bin", and this works fine for > all boards, so why cannot we make it that "u-boot-nand.bin" works for > all boards booting from NAND, and in general "u-boot-.bin" works > for all boards booting from a boot device? > > Instead of "onenand-ipl-2k.bin", we would just have a generic > "u-boot-onenand.bin" > >> Of course, this is assuming the existing Makefile structure. With the >> new Makefile structure you are suggesting this may not hold good. > > Why not? I was saying that my suggestion of delegating everything to board level Makefile will not work with the new top-down approach you are suggesting in the other mail-chain. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31: Improve the handling of unidentified silicon version
Hi Graeme, On 6/15/2011 9:08 AM, Graeme Russ wrote: ... > Does 'srev' have a more plain language description? or would somebody > reading that instantly know what 'srev' meant? Yes, srev is the exact term that is found on the MX31 Reference Manual - Table 13-2 Reading Wolfgang´s message he thinks it is better to discard this patch, so I am not going to send a v2. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31: Improve the handling of unidentified silicon version
On 06/15/2011 01:50 PM, Fabio Estevam wrote: > Hi Stefano, > Hi Fabio, > Let me try to explain the problem I see with the current silicon > detection mechanism: > > On my board (srev=0x28), which is a TO2.0 silicon I get: > > CPU: Freescale i.MX31 rev 2.0 at 531 MHz.Reset cause: WDOG > > On Felix´s MX31ADS board (srev=0x20) (unknown chip version) he gets: > > CPU: Freescale i.MX31 rev 2.0 unknown at 531 MHz.Reset cause: WDOG > > Reading rev 2.0 on Felix´s case is misleading IMHO as we tend to > think that we have a TO2.0 silicon on his board even though we get a > "unknown" string. Ok, so only reading the code we can know that version number + "unknown" give us the value of the srev register. We can explicitely expand the output to make things clearer. >>> if (srev == mx31_cpu_type[i].srev) return mx31_cpu_type[i].v; >>> >>> - return srev | 0x8000; + return 0x8000; >> >> IMHO in the case the revision is not recognized, it is better to >> print the value of the srev register, as it is done now. > > Yes, agreed, but we should print srev as an hex number instead of a > string as done today > > If you agree I can implement the following logic: > > When the chip version is detected let´s just leave as it is today: > > CPU: Freescale i.MX31 rev 2.0 at 531 MHz.Reset cause: WDOG > > When the chip version is not valid, then we print: > > CPU: Freescale i.MX31 (unknown rev, srev=0x20) at 531 MHz.Reset > cause: WDOG Agree with your proposal. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31: Improve the handling of unidentified silicon version
Hi Wolfgang, On 15/06/11 22:12, Wolfgang Denk wrote: > Dear Fabio Estevam, > > In message <4df89c84.7090...@freescale.com> you wrote: > ... >> CPU: Freescale i.MX31 rev 2.0 unknown at 531 MHz.Reset cause: WDOG > ... >> When the chip version is not valid, then we print: >> >> CPU: Freescale i.MX31 (unknown rev, srev=0x20) at 531 MHz.Reset cause: WDOG > > Compare to the current line above - which new information do you > print? None. You just print it in a new format, and with more > characters, i. e. with a worse SNR. > >> Please let me know what you think about this proposal. > > You received 3 messages from 3 different guys who told you all the > same: just leave the code as is. Your proposed changes are not > considered an improvement. But as Fabio has pointed out, the '2.0' in 'rev 2.0' is not srev - This highlights the root of the problem - (srev == 0x20) != (rev 2.0) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
On 15/06/11 22:04, Wolfgang Denk wrote: > Dear Aneesh V, > > In message <4df89102.9040...@ti.com> you wrote: >> >> Will you accept something like this? >> >> a_val = (reg & a_mask) >> a_shift; > > Yes, of course (that's what seems most natural to me). > Me too - The code is obvious - the desired value is being masked out of a larger composite value and then shifted right to bit 0 And to set the value then you have: reg &= ~a_mask; /* Clear a_val */ reg |= (a_val << a_shift) & a_mask; /* Set new a_val */ AND'ing with a_mask is required to prevent accidental clobbering when a_val is out-of-range. May give undesirable results by setting an illegal a_val, but at least you don't clobber unrelated bit fields Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/22] omap: add spl support
Dear Aneesh V, In message <4df8a0c0.2040...@ti.com> you wrote: > > >> Of course, this is assuming the existing Makefile structure. With the > >> new Makefile structure you are suggesting this may not hold good. > > > > Why not? > > I was saying that my suggestion of delegating everything to board level > Makefile will not work with the new top-down approach you are > suggesting in the other mail-chain. I did not suggest this. On contrary, I think I pointed out that we might have cases where no board directory (and thus no board specific Makefile) will be needed at all. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Many Myths are based on truth -- Spock, "The Way to Eden", stardate 5832.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31: Improve the handling of unidentified silicon version
Dear Stefano Babic, In message <4df8a2de.3040...@denx.de> you wrote: > > > Reading rev 2.0 on Felix=B4s case is misleading IMHO as we tend to > > think that we have a TO2.0 silicon on his board even though we get a > > "unknown" string. > > Ok, so only reading the code we can know that version number + "unknown" > give us the value of the srev register. We can explicitely expand the > output to make things clearer. Given that this is an exotic error case that happens only on a very small number of chips that are actually not supposed to exist at all, I think this is not worth the effort. The "unknown" is warning enough, and anybody who needs to know more details can see theremaining details easily from the code. > Agree with your proposal. No. We should not add code that is almost never ever useful anywhere, just to make this message more verbose. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Was heißt Windows auf Indianisch? - "Weißer Mann, der auf Sanduhr wartet!" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31: Improve the handling of unidentified silicon version
Dear Graeme Russ, In message <4df8a694.3030...@gmail.com> you wrote: > > But as Fabio has pointed out, the '2.0' in 'rev 2.0' is not srev - This > highlights the root of the problem - (srev == 0x20) != (rev 2.0) But everybody who spends half a minute on the problem can easily determine this, without adding code for an exotic error case. It's not any new information that gets printed, it's just minimally differently formatted. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Of course there's no reason for it, it's just our policy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Dear Graeme Russ, In message <4df8a8cf.5000...@gmail.com> you wrote: > > And to set the value then you have: > > reg &= ~a_mask; /* Clear a_val */ > reg |= (a_val << a_shift) & a_mask; /* Set new a_val */ This could be done using clrsetbits_le32(®, a_mask, a_val << a_shift); Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I think animal testing is a terrible idea; they get all nervous and give the wrong answers. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31: Improve the handling of unidentified silicon version
On 15/06/11 22:49, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message <4df8a694.3030...@gmail.com> you wrote: >> >> But as Fabio has pointed out, the '2.0' in 'rev 2.0' is not srev - This >> highlights the root of the problem - (srev == 0x20) != (rev 2.0) > > But everybody who spends half a minute on the problem can easily > determine this, without adding code for an exotic error case. Only if they know '(unknown)' changes the meaning of 'rev' to 'srev' - And that's the problem. If you don't have access to the code (or some fine documentation) how will you know that 'rev 2.0 (unknown)' means you need to search the SOC manual for 'srev == 0x20' > It's not any new information that gets printed, it's just minimally > differently formatted. It is more information - In the known case, you are printing mx31_cpu_type[i].v in the unknown case, you are printing srev Now I personally think that in itself is a no-no, but fixing it would mean doing something like: CPU: Freescale i.MX31 rev 2.0 (srev = 0x32) at 531 MHz.Reset cause: WDOG for the known case and CPU: Freescale i.MX31 unknown rev 0.0 (srev = 0x20) at 531 MHz.Reset cause: WDOG for the unknown case - Oops, we hit 80 characters :( Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31: Improve the handling of unidentified silicon version
On 06/15/2011 02:47 PM, Wolfgang Denk wrote: > Dear Stefano Babic, > Hi Wolfgang, > > Given that this is an exotic error case that happens only on a very > small number of chips that are actually not supposed to exist at all, Right, it can happen with some pre-production chips, as I understood from previous mails. > No. We should not add code that is almost never ever useful anywhere, > just to make this message more verbose. Ok. Let's the code as it is now. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Hi Wolfgang, On 15/06/11 22:51, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message <4df8a8cf.5000...@gmail.com> you wrote: >> >> And to set the value then you have: >> >> reg &= ~a_mask; /* Clear a_val */ >> reg |= (a_val << a_shift) & a_mask; /* Set new a_val */ > > This could be done using > > clrsetbits_le32(®, a_mask, a_val << a_shift); > Well the funny thing is, I find the former more obvious than the later ;) (but that's because I am not familiar with clrsetbits*) - But yes, 'I get it' Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Wolfgang,
Since discussion seems to have died down, I have assumed pseudo consensus
and have started hitting the timer cleanup in earnest. All I can say is:
Wow! What a mess ;)
> We could also design a more complicated API like this one, but I doubt
> this is needed:
Well, it is needed if you are measuring how long something has taken (say
erasing a Flash, performing an I/O operation, profiling boot-up etc)
>
> /*
>* round - used to control rounding:
>* <0 : round down, return time that has passed AT LEAST
>* =0 : don't round, provide raw time difference
>* >0 : round up, return time that has passed AT MOST
>*/
>u32 delta_timer(u32 from, u32 to, int round)
>{
[snip]
> }
I decided to implement three separate functions:
u32 time_ms_delta_min(u32 from, u32 to)
u32 time_ms_delta_max(u32 from, u32 to)
u32 time_ms_delta_raw(u32 from, u32 to)
So if you only use one, the rest get stripped out of the binary
The ms_ part allows for:
u32 time_us_delta_min(u32 from, u32 to)
u32 time_us_delta_max(u32 from, u32 to)
u32 time_us_delta_raw(u32 from, u32 to)
I intend to let the time_us_delta* functions drop to ms resolution of the
underlying tick counter is not sub-millisecond. Where the tick counter is
microsecond (or better), then arch-specific udelay becomes a trivial
implementation of a loop using time_us_now() and time_us_delta_min() -
Actually, we can make this a weak default and have arches with a non
microsecond tick counter override it.
> So our timeout from case 1) above would now be written like this:
>
> u32 start,now;
> u32 timeout = 5 * CONFIG_SYS_HZ; /* timeout after 5 seconds */
>
> start = get_timer(0);
I now have:
start = time_ms_now();
>
> while (test_for_event() == 0) {
> now = get_timer(0);
>
> if (delta_timer(start, now) > timeout)
> handle_timeout();
>
> udelay(100);
> }
>
> and would be guaranteed never to terminate early.
>
>
>
> Comments?
With the 'time_ms_' prefix, it's starting to get rather long, and I'm
pushing a lot of timeout checks beyond 80 columns - especially when
existing code has variables like 'start_time_tx' - I'm starting to consider
dropping the time_ prefix (all time functions will still have a ms_ or us_
prefix anyway) and rename a lot of variables
Thoughts?
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx31pdk: Add Networking commands
On 06/14/2011 04:02 PM, Fabio Estevam wrote: > Signed-off-by: Fabio Estevam > --- Hi Fabio, > include/configs/mx31pdk.h |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h > index ba1e187..77e93ab 100644 > --- a/include/configs/mx31pdk.h > +++ b/include/configs/mx31pdk.h > @@ -118,6 +118,10 @@ > #define CONFIG_SMC911X_BASE 0xB600 > #define CONFIG_SMC911X_32_BIT > > +#define CONFIG_CMD_PING This is already defined in mx31pdk.h > +#define CONFIG_CMD_DHCP > +#define CONFIG_CMD_MII ..and also CONFIG_CMD_MII Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx31pdk: Add DHCP command
Signed-off-by: Fabio Estevam --- include/configs/mx31pdk.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h index ba1e187..5f70023 100644 --- a/include/configs/mx31pdk.h +++ b/include/configs/mx31pdk.h @@ -88,6 +88,7 @@ #define CONFIG_CMD_MII #define CONFIG_CMD_PING +#define CONFIG_CMD_DHCP #define CONFIG_CMD_SPI #define CONFIG_CMD_DATE #define CONFIG_CMD_NAND -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10] Add support for Network Space v2 and parents
Hi Prafulla,
It appears that this v10 patch is also wrong. The specified email
encoding is UTF-8. It should be ISO-8859-1 which is the MAINTAINERS file
encoding. It is the reason why the patch is discarded by patchwork.
Please note that the patch diff is correct. The patch applies correctly
using git-am.
Let me know if a v11 is needed ?
Regards.
Simon
On Tue, Jun 14, 2011 at 09:13:51AM +, Simon Guinot wrote:
> Hi Prafulla,
>
> Please, consider pulling this patch.
>
> Regards,
>
> Simon
>
> On Sat, Jun 11, 2011 at 03:16:07PM +0200, Simon Guinot wrote:
> > This patch add support for the Network Space v2 board and parents, based
> > on the Marvell Kirkwood 6281 SoC. This include Network Space (Max) v2
> > and Internet Space v2.
> >
> > Additional information is available at:
> > http://lacie-nas.org/doku.php?id=network_space_v2
> >
> > Signed-off-by: Simon Guinot
> > ---
> > Changes for v2:
> > - add entries to MAINTAINERS file
> > - move boards from root Makefile to boards.cfg
> > - move MACH_TYPE definition into netspace_v2.h
> > - remove CONFIG_SYS_HZ redefinition
> > - turn PHY initialization message into debug()
> >
> > Changes for v3: none
> >
> > Changes for v4:
> > - enhance commit message: add SoC information
> >
> > Changes for v5: none
> >
> > Changes for v6:
> > - enable device tree support
> > - clean some "#define" in netspace_v2.h
> > - enhance commit message: provide description URL and mention SoC
> > family
> > - rebase against u-boot-{arm,marvell}/master branches
> >
> > Changes for v7:
> > - rebase against u-boot-marvell/master branch
> >
> > Changes for v8:
> > - update commit title (add netspace_v2 parents information).
> > - move GPIO button definition into header file.
> > - update CONFIG_IDENT_STRING with boards alias.
> > - handle wrong board definition.
> > - by default, use DHCP to get IP address.
> >
> > Changes for v9:
> > - rebase against u-boot-marvell/master branch
> >
> > Changes for v10:
> > - rebase against u-boot-marvell/master branch
> >
> > MAINTAINERS |6 +
> > board/LaCie/netspace_v2/Makefile | 49 ++
> > board/LaCie/netspace_v2/kwbimage.cfg | 162
> > +
> > board/LaCie/netspace_v2/netspace_v2.c | 142 +
> > board/LaCie/netspace_v2/netspace_v2.h | 42 +
> > boards.cfg|3 +
> > include/configs/netspace_v2.h | 162
> > +
> > 7 files changed, 566 insertions(+), 0 deletions(-)
> > create mode 100644 board/LaCie/netspace_v2/Makefile
> > create mode 100644 board/LaCie/netspace_v2/kwbimage.cfg
> > create mode 100644 board/LaCie/netspace_v2/netspace_v2.c
> > create mode 100644 board/LaCie/netspace_v2/netspace_v2.h
> > create mode 100644 include/configs/netspace_v2.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index c462ae2..ca27632 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -647,6 +647,12 @@ Sedji Gaouaou
> > at91sam9g10ek ARM926EJS (AT91SAM9G10 SoC)
> > at91sam9m10g45ekARM926EJS (AT91SAM9G45 SoC)
> >
> > +Simon Guinot
> > +
> > + inetspace_v2ARM926EJS (Kirkwood SoC)
> > + netspace_v2 ARM926EJS (Kirkwood SoC)
> > + netspace_max_v2 ARM926EJS (Kirkwood SoC)
> > +
> > Marius Gr?ger
> >
> > impa7 ARM720T (EP7211)
> > diff --git a/board/LaCie/netspace_v2/Makefile
> > b/board/LaCie/netspace_v2/Makefile
> > new file mode 100644
> > index 000..a245f2c
> > --- /dev/null
> > +++ b/board/LaCie/netspace_v2/Makefile
> > @@ -0,0 +1,49 @@
> > +#
> > +# Copyright (C) 2011 Simon Guinot
> > +#
> > +# Based on Kirkwood support:
> > +# (C) Copyright 2009
> > +# Marvell Semiconductor
> > +# Written-by: Prafulla Wadaskar
> > +#
> > +# 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.
> > +#
> > +
> > +include $(TOPDIR)/config.mk
> > +
> > +LIB= $(obj)lib$(BOARD).o
> > +
> > +COBJS := netspace_v2.o
> > +
> > +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> > +OBJS := $(addprefix $(obj),$(COBJS))
> > +SOBJS := $(addprefix $(obj),$(SOBJS))
> > +
> > +$(LIB):$(obj).depend $(OBJS) $(SOBJS)
> > + $(call cmd_link_o_target, $(OBJS) $(SOBJS))
> > +
> > +clean:
> > + rm -f $(SOBJS) $(OBJS)
> > +
> > +distclean: clean
> > + rm -f $(LIB) core *.bak .depend
> > +
> >
[U-Boot] [PATCH v3 0/5] updates for km ARM boards and board support for portl2
This is the third version of the patch serie. This patch serie was rebased on
top
of the two posted patches:
http://lists.denx.de/pipermail/u-boot/2011-June/094432.html
http://lists.denx.de/pipermail/u-boot/2011-June/094433.html
Initial cover letter message:
Beside the board support some small cleanup was done and the phy_reset funtion
for mgcoge3un was implemented.
Additionaly the suen3 and suen8 target are collected in one
target km_kirkwood. For new targets which differ only in the
usage of the PCI interface on kirkwood a target km_kirkwood_pci
was introduced, but they use all the same header file.
All keymile boards compile cleanly and checkpatch reports no errors or
warnings.
Holger Brunck (2):
arm/km: remove unneeded define
arm/km: replace suenx targets with km_kirkwood
Valentin Longchamp (3):
arm/km: use board KM_ENV_BUS for CONFIG_I2C_ENV_EEPROM_BUS
arm/km: ethernet support for mgcoge3un
arm/km: add support for portl2 board
MAINTAINERS|7 ++-
MAKEALL|3 +-
board/keymile/km_arm/km_arm.c | 45 ++-
boards.cfg |5 +-
include/configs/km/km_arm.h|4 +-
include/configs/{suen3.h => km_kirkwood.h} | 18 +--
include/configs/mgcoge3un.h|5 ++
include/configs/portl2.h | 81
include/configs/suen8.h| 50 -
9 files changed, 152 insertions(+), 66 deletions(-)
rename include/configs/{suen3.h => km_kirkwood.h} (77%)
create mode 100644 include/configs/portl2.h
delete mode 100644 include/configs/suen8.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/5] arm/km: remove unneeded define
CONFIG_ENV_SIZE for NAND was later in this file overwritten because we have the environment in i2c eeprom, so remove this define. Signed-off-by: Holger Brunck Signed-off-by: Valentin Longchamp cc: Prafulla Wadaskar cc: Heiko Schocher --- Changes for v3: - rebased Changes for v2: - nothing include/configs/km/km_arm.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h index 29815be..619acf0 100644 --- a/include/configs/km/km_arm.h +++ b/include/configs/km/km_arm.h @@ -55,7 +55,6 @@ #include "asm/arch/config.h" #define CONFIG_SYS_TEXT_BASE 0x0400 /* code address after reloc */ -#define CONFIG_ENV_SIZE(128 << 10) /* NAND chip block size */ #define CONFIG_SYS_MEMTEST_START 0x0040/* 4M */ #define CONFIG_SYS_MEMTEST_END 0x007f /*(_8M -1) */ #define CONFIG_SYS_LOAD_ADDR 0x0080 /* default load adr- 8M */ @@ -208,7 +207,6 @@ int get_scl(void); #define CONFIG_ENV_EEPROM_IS_ON_I2C #define CONFIG_SYS_EEPROM_WREN #define CONFIG_ENV_OFFSET 0x0 /* no bracets! */ -#undef CONFIG_ENV_SIZE #define CONFIG_ENV_SIZE(0x2000 - CONFIG_ENV_OFFSET) #define CONFIG_I2C_ENV_EEPROM_BUS "pca9547:70:d\0" -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/5] arm/km: use board KM_ENV_BUS for CONFIG_I2C_ENV_EEPROM_BUS
From: Valentin Longchamp This is defined for all km_kirkwood boards and was not used up to now. This value was the same for all boards but it could be changed for some boards (and thus needs to be defined for every board). Signed-off-by: Valentin Longchamp Signed-off-by: Holger Brunck cc: Prafulla Wadaskar cc: Heiko Schocher --- Changes for v3: - rebased Changes for v2: - the content is the same but patch is now 2/5 instead 5/6 include/configs/km/km_arm.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h index 619acf0..3ea0d62 100644 --- a/include/configs/km/km_arm.h +++ b/include/configs/km/km_arm.h @@ -208,7 +208,7 @@ int get_scl(void); #define CONFIG_SYS_EEPROM_WREN #define CONFIG_ENV_OFFSET 0x0 /* no bracets! */ #define CONFIG_ENV_SIZE(0x2000 - CONFIG_ENV_OFFSET) -#define CONFIG_I2C_ENV_EEPROM_BUS "pca9547:70:d\0" +#define CONFIG_I2C_ENV_EEPROM_BUS KM_ENV_BUS "\0" /* offset redund: (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) */ #define CONFIG_SYS_REDUNDAND_ENVIRONMENT -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/5] arm/km: ethernet support for mgcoge3un
From: Valentin Longchamp
The phy is also configured with "RGMII clock transitions when data
stable" and "Class A driver for the direct backplane connection".
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
cc: Prafulla Wadaskar
cc: Heiko Schocher
---
Changes for v3:
- rebased
Changes for v2:
- first version has also defines for portl2, they were removed because
the board support for portl2 has moved to the end of the serie
board/keymile/km_arm/km_arm.c | 39 ++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index d86acc9..ed6ede3 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -335,7 +335,42 @@ void dram_init_banksize(void)
}
}
-/* Configure and enable MV88E1118 PHY */
+#if defined(CONFIG_MGCOGE3UN)
+
+#definePHY_LED_SEL 0x18
+#define PHY_LED0_LINK (0x5)
+#define PHY_LED1_ACT (0x8<<4)
+#define PHY_LED2_INT (0xe<<8)
+#definePHY_SPEC_CTRL 0x1c
+#define PHY_RGMII_CLK_STABLE (0x1<<10)
+#define PHY_CLSA (0x1<<1)
+
+/* Configure and enable MV88E3018 PHY */
+void reset_phy(void)
+{
+ char *name = "egiga0";
+ unsigned short reg;
+
+ if (miiphy_set_current_dev(name))
+ return;
+
+ /* RGMII clk transition on data stable */
+ if (miiphy_read(name, CONFIG_PHY_BASE_ADR, PHY_SPEC_CTRL, ®) != 0)
+ printf("Error reading PHY spec ctrl reg\n");
+ if (miiphy_write(name, CONFIG_PHY_BASE_ADR, PHY_SPEC_CTRL,
+ reg | PHY_RGMII_CLK_STABLE | PHY_CLSA) != 0)
+ printf("Error writing PHY spec ctrl reg\n");
+
+ /* leds setup */
+ if (miiphy_write(name, CONFIG_PHY_BASE_ADR, PHY_LED_SEL,
+ PHY_LED0_LINK | PHY_LED1_ACT | PHY_LED2_INT) != 0)
+ printf("Error writing PHY LED reg\n");
+
+ /* reset the phy */
+ miiphy_reset(name, CONFIG_PHY_BASE_ADR);
+}
+#else
+/* Configure and enable MV88E1118 PHY on the piggy*/
void reset_phy(void)
{
char *name = "egiga0";
@@ -346,6 +381,8 @@ void reset_phy(void)
/* reset the phy */
miiphy_reset(name, CONFIG_PHY_BASE_ADR);
}
+#endif
+
#if defined(CONFIG_HUSH_INIT_VAR)
int hush_init_var(void)
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 5/5] arm/km: add support for portl2 board
From: Valentin Longchamp
This adds support for the keymile Kirkwood BEC portl2 board. This board
relies on the km_arm (km_kirkwood) BEC.
The egiga driver is configured for a 100M full-duplex, A/N off connnection
to the backplane. This board has always ethernet present, because it is
connected to the marvell switch similar to mgcoge3un. The reset_phy
functionality is also the same to mgcoge3un.
Signed-off-by: Valentin Longchamp
Signed-off-by: Holger Brunck
cc: Prafulla Wadaskar
cc: Heiko Schocher
---
Changes for v3:
- rebase
Changes for v2:
- add this board support patch to the end of the serie
MAINTAINERS |1 +
MAKEALL |1 +
board/keymile/km_arm/km_arm.c |8 +++--
boards.cfg|1 +
include/configs/portl2.h | 81 +
5 files changed, 89 insertions(+), 3 deletions(-)
create mode 100644 include/configs/portl2.h
diff --git a/MAINTAINERS b/MAINTAINERS
index d1ec392..653c928 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -729,6 +729,7 @@ Sergey Lapin
Valentin Longchamp
km_kirkwood ARM926EJS (Kirkwood SoC)
+ portl2 ARM926EJS (Kirkwood SoC)
Nishanth Menon
diff --git a/MAKEALL b/MAKEALL
index 1798303..3f92449 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -364,6 +364,7 @@ LIST_ARM9=" \
openrd_base \
openrd_client \
openrd_ultimate \
+ portl2 \
rd6281a \
sbc2410x\
scb9328 \
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index ed6ede3..5da856f 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -130,10 +130,12 @@ int startup_allowed(void)
return 1;
return 0;
}
+#endif
+#if (defined(CONFIG_MGCOGE3UN)|defined(CONFIG_PORTL2))
/*
- * mgcoge3un has always ethernet present. Its connected to the 6061 switch
- * and provides ICNev and piggy4 connections.
+ * These two boards have always ethernet present. Its connected to the mv
+ * switch.
*/
int ethernet_present(void)
{
@@ -335,7 +337,7 @@ void dram_init_banksize(void)
}
}
-#if defined(CONFIG_MGCOGE3UN)
+#if (defined(CONFIG_MGCOGE3UN)|defined(CONFIG_PORTL2))
#definePHY_LED_SEL 0x18
#define PHY_LED0_LINK (0x5)
diff --git a/boards.cfg b/boards.cfg
index 6a50236..649f1af 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -109,6 +109,7 @@ davinci_sonata arm arm926ejs sonata
davinci
km_kirkwood arm arm926ejs km_arm
keymilekirkwood km_kirkwood:KM_DISABLE_PCI
km_kirkwood_pci arm arm926ejs km_arm
keymilekirkwood km_kirkwood
mgcoge3unarm arm926ejs km_arm
keymilekirkwood
+portl2 arm arm926ejs km_arm
keymilekirkwood
guruplug arm arm926ejs -
Marvellkirkwood
mv88f6281gtw_ge arm arm926ejs -
Marvellkirkwood
openrd_base arm arm926ejs openrd
Marvellkirkwoodopenrd:BOARD_IS_OPENRD_BASE
diff --git a/include/configs/portl2.h b/include/configs/portl2.h
new file mode 100644
index 000..a8543a5
--- /dev/null
+++ b/include/configs/portl2.h
@@ -0,0 +1,81 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor
+ * Prafulla Wadaskar
+ *
+ * (C) Copyright 2009
+ * Stefan Roese, DENX Software Engineering, s...@denx.de.
+ *
+ * (C) Copyright 2010-2011
+ * Holger Brunck, Keymile GmbH Hannover, holger.bru...@keymile.com.
+ * Valentin Longchamp, Keymile AG Bern, valentin.longch...@keymile.com
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+/* for linking errors see
+ * http://lists.denx.de/pipermail/u-boot/2009-July/057350.html */
+
+#ifndef _CONFIG_PORTL2_H
+#define _CONFIG_PORTL2_H
+
+/* include common defines/options for all arm based Keymile boards */
+#include "km/km_arm.h"
+
[U-Boot] [PATCH v3 4/5] arm/km: replace suenx targets with km_kirkwood
suen3 and suen8 were in first HW version quite different, but
now they are from a u-boot point of view similar. So these
two boards can use the same header file. Other keymile boards
differ only in the usage of the PCI interface. Therefore
a target km_kirkwood_pci was introduced. All targets use
the same header file.
Signed-off-by: Holger Brunck
Signed-off-by: Valentin Longchamp
cc: Prafulla Wadaskar
cc: Heiko Schocher
---
Changes for v3:
- rebased
Changes for v2:
- squashed together with 5/6 from previous serie, because
the pci defines belongs logically to this patch
- change typo in board maintainers name
MAINTAINERS|6 ++-
MAKEALL|2 +-
boards.cfg |4 +-
include/configs/{suen3.h => km_kirkwood.h} | 18 +++---
include/configs/mgcoge3un.h|5 +++
include/configs/suen8.h| 50
6 files changed, 25 insertions(+), 60 deletions(-)
rename include/configs/{suen3.h => km_kirkwood.h} (77%)
delete mode 100644 include/configs/suen8.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c462ae2..d1ec392 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -726,6 +726,10 @@ Sergey Lapin
afeb9260ARM926EJS (AT91SAM9260 SoC)
+Valentin Longchamp
+
+ km_kirkwood ARM926EJS (Kirkwood SoC)
+
Nishanth Menon
omap3_sdp3430 ARM ARMV7 (OMAP3xx SoC)
@@ -814,8 +818,6 @@ Heiko Schocher
magnesium i.MX27
mgcoge3un ARM926EJS (Kirkwood SoC)
- suen3 ARM926EJS (Kirkwood SoC)
- suen8 ARM926EJS (Kirkwood SoC)
Robert Schwebel
diff --git a/MAKEALL b/MAKEALL
index d592374..1798303 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -347,6 +347,7 @@ LIST_ARM9=" \
guruplug\
imx27lite \
jadecpu \
+ km_kirkwood \
lpd7a400\
magnesium \
mv88f6281gtw_ge \
@@ -373,7 +374,6 @@ LIST_ARM9=" \
spear310\
spear320\
spear600\
- suen3 \
trab\
VCMA9 \
versatile \
diff --git a/boards.cfg b/boards.cfg
index d2cacc8..6a50236 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -106,8 +106,8 @@ davinci_dvevmarm arm926ejs dvevm
davinci
davinci_schmoogiearm arm926ejs schmoogie
davincidavinci
davinci_sffsdr arm arm926ejs sffsdr
davincidavinci
davinci_sonata arm arm926ejs sonata
davincidavinci
-suen3arm arm926ejs km_arm
keymilekirkwood
-suen8arm arm926ejs km_arm
keymilekirkwood
+km_kirkwood arm arm926ejs km_arm
keymilekirkwood km_kirkwood:KM_DISABLE_PCI
+km_kirkwood_pci arm arm926ejs km_arm
keymilekirkwood km_kirkwood
mgcoge3unarm arm926ejs km_arm
keymilekirkwood
guruplug arm arm926ejs -
Marvellkirkwood
mv88f6281gtw_ge arm arm926ejs -
Marvellkirkwood
diff --git a/include/configs/suen3.h b/include/configs/km_kirkwood.h
similarity index 77%
rename from include/configs/suen3.h
rename to include/configs/km_kirkwood.h
index 0f1b11e..e51b270 100644
--- a/include/configs/suen3.h
+++ b/include/configs/km_kirkwood.h
@@ -6,6 +6,9 @@
* (C) Copyright 2009
* Stefan Roese, DENX Software Engineering, s...@denx.de.
*
+ * (C) Copyright 2011
+ * Holger Brunck, Keymile GmbH Hannover, holger.bru...@keymile.de
+ *
* See file CREDITS for list of people who contributed to this
* project.
*
@@ -30,8 +33,8 @@
* http://lists.denx.de/pipermail/u-boot/2009-July/057350.html
*/
-#ifndef _CONFIG_SUEN3_H
-#define _CONFIG_SUEN3_H
+#ifndef _CONFIG_KM_KIRKWOOD_H
+#define _CONFIG_KM_KIRKWOOD_H
/* include common defines/options for all arm based Keymile boards */
#include "km/km_arm.h"
@@ -39,11 +42,16 @@
/*
* Version number information
*/
-#define CONFIG_IDENT_STRING"\nKeymile SUEN3"
+#ifdef CONFIG_KM_DISABLE_PCI
+#define CONFIG_IDENT_STRING"\nKeymile Kirkwood"
+#undef CONFIG_KIRKWOOD_PCIE_INIT
+#else
+#define CONFIG_IDENT_STRING"\nKeymile Kirkwood PCI"
+#endif
-#define CONFIG_HOSTNAMEsuen3
+#define CONFIG_HOSTNAMEkm_kirkwood
#define KM_IVM_BUS "pca9544a:70:9" /* I2C2 (Mux-Port 1)*/
#define KM_ENV_BUS "pca9544a:70:d" /* I2C2
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
On Tue, Jun 14, 2011 at 11:54 AM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message you wrote: >> >> > Looking closer, the "FIELD_VAL" macro alone will probably not suffice, >> > as you need both shift directions, like that: >> > >> > #define FIELD_SHIFT 16 >> > #define FIELD_MASK 0xF >> > >> > >> > #define FIELD_BITS(x) (x << 16) >> > #define FIELD_MASK FIELD_BITS(0xF) >> > #define FIELD_VAL(x) ((x & FIELD_MASK) >> 16) >> >> Hi Wolfgang, >> >> I think you have FIELD_MASK being two meanings: the un-shifted or >> 'raw' mask, and the shifted mask. So perhaps: > > My intention was to have only the real mask, i. e. what you need to > apply to the register data (in your language the shifted mask). > >> #define FIELD_SHIFT 16 >> #define FIELD_RAWMASK 0xF > > This is never really needed - you only use it once. > >> When you have a lot of these definitions in a row you have mentally >> check the bit width of the mask: > > Yes, this is one of the disadvantages of thinking in bit fields and > one reason why I never write code like that. > > I mentioned this before - I consider it error prone [like most other > "clever" tricks that "make life easy" and allow you to stop thinking]. > >> Is the above correct, or do fields overlap or not cover fully? > > All this is possible. There may be overlapping definitions, and there > may be reserved bits that need special handling. > > There may even be bits that cannot simply be re-writeen as we read > them, but that must always be written as zeroes or ones. > > I never claimed that these "bit field" juggling was a clever idea. > It works for some cases, and causes major pita for others. Hi Wolfgang, Yes I agree, but I think you might have missed both my points. Regards, Simon > > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > In an organization, each person rises to the level of his own incom- > petency - The Peter Principle > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sequoia board can't run itself
myfrends, I am porting a boot from sequoia. I have use the BDI3000 to load the u-boot.bin and flash to norflash. I can trace the codes by BDI3000 and receive the u-boot info from uart as following. but when I try to power on and run the codes itself but not use BDI3000 to send "go". there are not any characters from the uart port. I have no idea to find the bug. have any one can give some advice? Best Regerd. Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Graeme,
On Wed, Jun 15, 2011 at 6:17 AM, Graeme Russ wrote:
> Hi Wolfgang,
...
>>
>> /*
>> * round - used to control rounding:
>> * <0 : round down, return time that has passed AT LEAST
>> * =0 : don't round, provide raw time difference
>> * >0 : round up, return time that has passed AT MOST
>> */
>> u32 delta_timer(u32 from, u32 to, int round)
>> {
>
> [snip]
>
>> }
>
> I decided to implement three separate functions:
>
> u32 time_ms_delta_min(u32 from, u32 to)
> u32 time_ms_delta_max(u32 from, u32 to)
> u32 time_ms_delta_raw(u32 from, u32 to)
>
> So if you only use one, the rest get stripped out of the binary
Here is m 2p worth:
- the common case is min I think, so let's get rid of the min prefix
so everyone will use it without question or needing to read screeds of
doc
- would prefer the ms and us at the end as I think it reads better.
Getting the time is the important bit - the units are generally at the
end
This code from your excellent wiki page bothers me. Can we find a way
to shrink it?
now = timer_ms_now();
if (time_ms_delta_min(start, now)> timeout)
How about:
if (time_since_ms(start) > timeout)
The idea of the time 'since' an event is more natural than the delta
between then and now which seems more abstract.
>
> The ms_ part allows for:
>
> u32 time_us_delta_min(u32 from, u32 to)
> u32 time_us_delta_max(u32 from, u32 to)
> u32 time_us_delta_raw(u32 from, u32 to)
>
> I intend to let the time_us_delta* functions drop to ms resolution of the
> underlying tick counter is not sub-millisecond. Where the tick counter is
> microsecond (or better), then arch-specific udelay becomes a trivial
> implementation of a loop using time_us_now() and time_us_delta_min() -
> Actually, we can make this a weak default and have arches with a non
> microsecond tick counter override it.
>
>> So our timeout from case 1) above would now be written like this:
>>
>> u32 start,now;
>> u32 timeout = 5 * CONFIG_SYS_HZ; /* timeout after 5 seconds */
>>
>> start = get_timer(0);
>
> I now have:
> start = time_ms_now();
>
>>
>> while (test_for_event() == 0) {
>> now = get_timer(0);
>>
>> if (delta_timer(start, now) > timeout)
>> handle_timeout();
>>
>> udelay(100);
>> }
>>
>> and would be guaranteed never to terminate early.
>>
>>
>>
>> Comments?
>
> With the 'time_ms_' prefix, it's starting to get rather long, and I'm
> pushing a lot of timeout checks beyond 80 columns - especially when
> existing code has variables like 'start_time_tx' - I'm starting to consider
> dropping the time_ prefix (all time functions will still have a ms_ or us_
> prefix anyway) and rename a lot of variables
Now I see why you want units at the start. Seems a bit ugly to me -
which lines are getting long - do you mean the time delta check line?
If so see above, or perhaps it is shorter without _min.
Regards,
Simon
>
> Thoughts?
>
> Regards,
>
> Graeme
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] a l'attention du responsable Technique
== Message composé et expédié avec la version d'évaluation gratuite de Sarbacane®, le logiciel d'e-mailing professionnel pour Windows de GOTO Software. Attention, GOTO n'est responsable ni du contenu de ce message ni du fait qu'il vous a été expédié. Pour toute question au sujet de ce message, merci de prendre contact avec l'expéditeur. == <>___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Booting uncompressed uImages
Hi all, I've got an interesting issue with a MIPS board I'm working on. The uncompressed uImage has been created with a Load Address of 0x8050 and an Entry Point of 0x80504590. This gets TFTP's into RAM at 0x8055b728. When I run a "bootm 0x8055b728" this image fails to run. Tracing through the code, I see that in bootm_load_os() it follows the IH_COMP_NONE path for non XIP images. This should copy the uImage to the load address so it can be executed. However, the copy command is : memmove_wd ((void *)load, (void *)image_start, image_len, CHUNKSZ); This actually copies the image 'payload' instead of the whole uImage thereby dropping 64 bytes from the front of the copy and moving the entry point. (I've verified this by breaking into the process and looking at the source and destinations of the copy and comparing to an XIP bootm invocation) I've scratched my head as I'm really surprised that it behaves this way with a zillion boards out there, BUT from digging via google it seems that the world and his/her dog nearly always use the same address for both load address and entry point which subsequently masks this behaviour in that particular case. I've verified that if I change to : memmove_wd ((void *)load, (void *)blob_start, image_len + (blob_end - blob_start), CHUNKSZ); Then the kernel boot works as I'd expect it to. Can anyone sanity-check my reasoning here and tell me if this is the correct fix or if I'm being mislead by something more insidious that just happens to present itself in this way? Cheers! ~Pev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
On 16/06/11 02:03, Simon Glass wrote:
> Hi Graeme,
>
> On Wed, Jun 15, 2011 at 6:17 AM, Graeme Russ wrote:
>> Hi Wolfgang,
> ...
>>>
>>> /*
>>>* round - used to control rounding:
>>>* <0 : round down, return time that has passed AT LEAST
>>>* =0 : don't round, provide raw time difference
>>>* >0 : round up, return time that has passed AT MOST
>>>*/
>>>u32 delta_timer(u32 from, u32 to, int round)
>>>{
>>
>> [snip]
>>
>>> }
>>
>> I decided to implement three separate functions:
>>
>> u32 time_ms_delta_min(u32 from, u32 to)
>> u32 time_ms_delta_max(u32 from, u32 to)
>> u32 time_ms_delta_raw(u32 from, u32 to)
>>
>> So if you only use one, the rest get stripped out of the binary
>
> Here is m 2p worth:
>
> - the common case is min I think, so let's get rid of the min prefix
> so everyone will use it without question or needing to read screeds of
> doc
I don't like this idea - Extrapolate this to dropping the 'ms' common case
and you end up with:
u32 time_delta(u32 from, u32 to)
u32 time_delta_max(u32 from, u32 to)
u32 time_delta_raw(u32 from, u32 to)
u32 time_us_delta(u32 from, u32 to)
u32 time_us_delta_max(u32 from, u32 to)
u32 time_us_delta_raw(u32 from, u32 to)
Not as grep'able IMHO
> - would prefer the ms and us at the end as I think it reads better.
> Getting the time is the important bit - the units are generally at the
> end
Hmm, time_since_ms or time_ms_since - I suppose either reads OK - But if I
keep min/max/raw, I find time_min_ms_since (barely) easier in the eye than
time_min_since_ms - I'm not bothered either way and will go with the
general consensus
> This code from your excellent wiki page bothers me. Can we find a way
> to shrink it?
>
> now = timer_ms_now();
> if (time_ms_delta_min(start, now)> timeout)
>
> How about:
>
> if (time_since_ms(start) > timeout)
>
> The idea of the time 'since' an event is more natural than the delta
> between then and now which seems more abstract.
I tend to agree - I have been thinking about 'since' functions for a while now
[snip]
>>
>> With the 'time_ms_' prefix, it's starting to get rather long, and I'm
>> pushing a lot of timeout checks beyond 80 columns - especially when
>> existing code has variables like 'start_time_tx' - I'm starting to consider
>> dropping the time_ prefix (all time functions will still have a ms_ or us_
>> prefix anyway) and rename a lot of variables
>
> Now I see why you want units at the start. Seems a bit ugly to me -
> which lines are getting long - do you mean the time delta check line?
> If so see above, or perhaps it is shorter without _min.
An example from drivers/net/ns7520_eth.c:
ulStartJiffies = time_ms_now();
while (time_ms_delta_min(ulStartJiffies, time_ms_now())
< NS7520_MII_NEG_DELAY) {
Could be reduced to:
ulStartJiffies = time_ms_now();
while (time_min_ms_since(ulStartJiffies) < NS7520_MII_NEG_DELAY) {
And with a rename:
start_ms = time_ms_now();
while (time_min_ms_since(start_ms) < NS7520_MII_NEG_DELAY) {
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting uncompressed uImages
Dear David Peverley, In message you wrote: > > I've got an interesting issue with a MIPS board I'm working on. The > uncompressed uImage has been created with a Load Address of 0x8050 > and an Entry Point of 0x80504590. This gets TFTP's into RAM at > 0x8055b728. When I run a "bootm 0x8055b728" this image fails to run. Why using such an odd address as 0x8055b728? Please be aware that is just 365 KB above your load address, and I guess your kernel image is way bigger than 365 KB. > This actually copies the image 'payload' instead of the whole uImage > thereby dropping 64 bytes from the front of the copy and moving the > entry point. (I've verified this by breaking into the process and It does not "move the entry point". The entry point address is a constant address and does never move. > Can anyone sanity-check my reasoning here and tell me if this is the > correct fix or if I'm being mislead by something more insidious that > just happens to present itself in this way? Just follow the rules and never download the image to an address range that overlaps with the area where the image will be unpacked / loaded to. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The use of Microsoft crippleware systems is a sin that carries with it its own punishment. -- Tom Christiansen in <6bo3fr$pj8$5...@csnews.cs.colorado.edu> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_dma: fix support for 83xx DMA engine
On Tue, Mar 01, 2011 at 02:40:55PM -0800, Ira W. Snyder wrote:
> Commit 359ec4931944adb885882deb9b781e4095eabc94 broke support for the
> Freescale DMA engine on the 83xx parts. This is due to using registers
> which do not exist on 83xx. Remove the attribute register accesses from
> the 83xx build.
>
Hi everyone,
This never made it into mainline. I think it is a pretty obvious build
error on 83xx platforms. Can someone pick it up?
Thanks,
Ira
> Signed-off-by: Ira W. Snyder
> Cc: York Sun
> Cc: Peter Tyser
> Cc: Kumar Gala
> ---
> drivers/dma/fsl_dma.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dma/fsl_dma.c b/drivers/dma/fsl_dma.c
> index 09c18c1..30785ec 100644
> --- a/drivers/dma/fsl_dma.c
> +++ b/drivers/dma/fsl_dma.c
> @@ -116,10 +116,12 @@ int dmacpy(phys_addr_t dest, phys_addr_t src,
> phys_size_t count) {
>
> out_dma32(&dma->dar, (u32) (dest & 0x));
> out_dma32(&dma->sar, (u32) (src & 0x));
> +#if !defined(CONFIG_MPC83xx)
> out_dma32(&dma->satr,
> in_dma32(&dma->satr) | (u32)((u64)src >> 32));
> out_dma32(&dma->datr,
> in_dma32(&dma->datr) | (u32)((u64)dest >> 32));
> +#endif
> out_dma32(&dma->bcr, xfer_size);
> dma_sync();
>
> --
> 1.7.3.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: make it possible to build tools unconfigured
Sometimes we want to build common tools without configuring for specific
target. Currently top Makefile has some support for this but it doesn't
work. This patch tries to fix this.
Things changed:
- config.mk disable 'ld script not found error' in case if we are
building tools only.
- Makefilemkimage relies on autogenerated version so we need to
move $(VERSION_FILE) rule out of ifeq and make tools rule depend on it.
- tools/Makefile put common/env_embedded.o and envcrc.o to object list
conditionally. This fixes errors during dependency generation.
Signed-off-by: Ilya Yanok
---
Makefile | 34 +-
config.mk |2 ++
tools/Makefile | 19 ---
3 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/Makefile b/Makefile
index dcf5d93..4f7326e 100644
--- a/Makefile
+++ b/Makefile
@@ -140,7 +140,7 @@ SUBDIRS = tools \
examples/standalone \
examples/api
-.PHONY : $(SUBDIRS)
+.PHONY : $(SUBDIRS) $(VERSION_FILE)
ifeq ($(obj)include/config.mk,$(wildcard $(obj)include/config.mk))
@@ -422,19 +422,6 @@ mmc_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
-$(VERSION_FILE):
- @( localvers='$(shell $(TOPDIR)/tools/setlocalversion
$(TOPDIR))' ; \
- printf '#define PLAIN_VERSION "%s%s"\n' \
- "$(U_BOOT_VERSION)" "$${localvers}" ; \
- printf '#define U_BOOT_VERSION "U-Boot %s%s"\n' \
- "$(U_BOOT_VERSION)" "$${localvers}" ; \
- ) > $@.tmp
- @( printf '#define CC_VERSION_STRING "%s"\n' \
-'$(shell $(CC) --version | head -n 1)' )>> $@.tmp
- @( printf '#define LD_VERSION_STRING "%s"\n' \
-'$(shell $(LD) -v | head -n 1)' )>> $@.tmp
- @cmp -s $@ $@.tmp && rm -f $@.tmp || mv -f $@.tmp $@
-
$(TIMESTAMP_FILE):
@LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"' > $@
@LC_ALL=C date +'#define U_BOOT_TIME "%T"' >> $@
@@ -509,20 +496,33 @@ $(obj)lib/asm-offsets.s: $(obj)include/autoconf.mk.dep \
else # !config.mk
all $(obj)u-boot.hex $(obj)u-boot.srec $(obj)u-boot.bin \
$(obj)u-boot.img $(obj)u-boot.dis $(obj)u-boot \
-$(filter-out tools,$(SUBDIRS)) $(TIMESTAMP_FILE) $(VERSION_FILE) \
+$(filter-out tools,$(SUBDIRS)) $(TIMESTAMP_FILE) \
updater depend dep tags ctags etags cscope $(obj)System.map:
@echo "System not configured - see README" >&2
@ exit 1
-tools:
+tools: $(VERSION_FILE)
$(MAKE) -C $@ all
endif # config.mk
+$(VERSION_FILE):
+ @( localvers='$(shell $(TOPDIR)/tools/setlocalversion
$(TOPDIR))' ; \
+ printf '#define PLAIN_VERSION "%s%s"\n' \
+ "$(U_BOOT_VERSION)" "$${localvers}" ; \
+ printf '#define U_BOOT_VERSION "U-Boot %s%s"\n' \
+ "$(U_BOOT_VERSION)" "$${localvers}" ; \
+ ) > $@.tmp
+ @( printf '#define CC_VERSION_STRING "%s"\n' \
+'$(shell $(CC) --version | head -n 1)' )>> $@.tmp
+ @( printf '#define LD_VERSION_STRING "%s"\n' \
+'$(shell $(LD) -v | head -n 1)' )>> $@.tmp
+ @cmp -s $@ $@.tmp && rm -f $@.tmp || mv -f $@.tmp $@
+
easylogo env gdb:
$(MAKE) -C tools/$@ all MTD_VERSION=${MTD_VERSION}
gdbtools: gdb
-tools-all: easylogo env gdb
+tools-all: easylogo env gdb $(VERSION_FILE)
$(MAKE) -C tools HOST_TOOLS_ALL=y
.PHONY : CHANGELOG
diff --git a/config.mk b/config.mk
index 7ce554e..51994f2 100644
--- a/config.mk
+++ b/config.mk
@@ -180,7 +180,9 @@ ifndef LDSCRIPT
LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot.lds
endif
ifeq ($(wildcard $(LDSCRIPT)),)
+ ifeq ($(obj)include/config.mk,$(wildcard
$(obj)include/config.mk))
$(error could not find linker script)
+ endif
endif
endif
diff --git a/tools/Makefile b/tools/Makefile
index 623f908..30ae0b5 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -67,7 +67,14 @@ BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
# Source files which exist outside the tools directory
-EXT_OBJ_FILES-y += common/env_embedded.o
+EXT_OBJ_FILES-$(CONFIG_ENV_IS_EMBEDDED) += common/env_embedded.o
+EXT_OBJ_FILES-$(CONFIG_ENV_IS_IN_DATAFLASH) += common/env_embedded.o
+EXT_OBJ_FILES-$(CONFIG_ENV_IS_IN_EEPROM) += common/env_embedded.o
+EXT_OBJ_FILES-$(CONFIG_ENV_IS_IN_FLASH) += common/env_embedded.o
+EXT_OBJ_FILES-$(CONFIG_ENV_IS_IN_ONENAND) += common/env_embedded.o
+EXT_OBJ_FILES-$(CONFIG_ENV_IS_IN_NAND) += common/env_embedded.o
+EXT_OBJ_FILES-$(CONFIG_ENV_IS_IN_NVRAM) += common/env_embedded.o
+EXT_OBJ_FILES-$(CONFIG_ENV_IS_IN_SPI_FLASH) += common/env_embedded.o
EXT_OBJ_FILES-y += common/image.o
EXT_OBJ_FILES-y += lib/crc32.o
EXT_OBJ_FILES-y += lib/md5.o
@@ -77,7 +84,14 @@ EXT_OB
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Graeme,
On Wed, Jun 15, 2011 at 1:38 PM, Graeme Russ wrote:
> On 16/06/11 02:03, Simon Glass wrote:
>> - the common case is min I think, so let's get rid of the min prefix
>> so everyone will use it without question or needing to read screeds of
>> doc
>
> I don't like this idea - Extrapolate this to dropping the 'ms' common case
> and you end up with:
>
> u32 time_delta(u32 from, u32 to)
> u32 time_delta_max(u32 from, u32 to)
> u32 time_delta_raw(u32 from, u32 to)
>
> u32 time_us_delta(u32 from, u32 to)
> u32 time_us_delta_max(u32 from, u32 to)
> u32 time_us_delta_raw(u32 from, u32 to)
>
> Not as grep'able IMHO
The reason I suggested this is not because it is common, in that ms is
more common than us. It is that users will find time_ms_delta_min
confusing. There is a min, max and raw - which should they use? While
everyone on this list is a genius there will be other people who will
choose one at random and run with it.
To my mind 'min' is the safe one and the others will be rarely used.
I agree that removing ms is a bad idea. But this is pretty grep'able
for sensible values of grep:
u32 time_delta_ms(u32 from, u32 to)
u32 time_delta_us(u32 from, u32 to)
[hide these away in the closet:
u32 time_delta_max_ms(u32 from, u32 to)
u32 time_delta_raw_ms(u32 from, u32 to)
u32 time_delta_max_us(u32 from, u32 to)
u32 time_delta_raw_us(u32 from, u32 to)
]
int time_since_ms(u32 from)
Also bear in mind that _us() will be seldom used. I will cheerfully
use it for boot timing though.
BTW should the deltas return a signed value?
>
>> - would prefer the ms and us at the end as I think it reads better.
>> Getting the time is the important bit - the units are generally at the
>> end
>
> Hmm, time_since_ms or time_ms_since - I suppose either reads OK - But if I
> keep min/max/raw, I find time_min_ms_since (barely) easier in the eye than
> time_min_since_ms - I'm not bothered either way and will go with the
> general consensus
No I mean _ms at the end, so it is always last. time_min_ms_since()
sounds like a martian trying to learn English. See my comment above:
time_since_ms() - we shouldn't even define time_since_raw_ms() and
time_since_max_ms() in my view.
>
>> This code from your excellent wiki page bothers me. Can we find a way
>> to shrink it?
>>
>> now = timer_ms_now();
>> if (time_ms_delta_min(start, now)> timeout)
>>
>> How about:
>>
>> if (time_since_ms(start) > timeout)
>>
>> The idea of the time 'since' an event is more natural than the delta
>> between then and now which seems more abstract.
>
> I tend to agree - I have been thinking about 'since' functions for a while now
Cool.
>
> [snip]
>
>>>
>>> With the 'time_ms_' prefix, it's starting to get rather long, and I'm
>>> pushing a lot of timeout checks beyond 80 columns - especially when
>>> existing code has variables like 'start_time_tx' - I'm starting to consider
>>> dropping the time_ prefix (all time functions will still have a ms_ or us_
>>> prefix anyway) and rename a lot of variables
>>
>> Now I see why you want units at the start. Seems a bit ugly to me -
>> which lines are getting long - do you mean the time delta check line?
>> If so see above, or perhaps it is shorter without _min.
>
> An example from drivers/net/ns7520_eth.c:
>
> ulStartJiffies = time_ms_now();
> while (time_ms_delta_min(ulStartJiffies, time_ms_now())
> < NS7520_MII_NEG_DELAY) {
>
> Could be reduced to:
>
> ulStartJiffies = time_ms_now();
> while (time_min_ms_since(ulStartJiffies) < NS7520_MII_NEG_DELAY) {
>
> And with a rename:
>
> start_ms = time_ms_now();
> while (time_min_ms_since(start_ms) < NS7520_MII_NEG_DELAY) {
>
or:
start_ms = time_now_ms();
while (time_since_ms(start_ms) < NS7520_MII_NEG_DELAY) {
Regards,
Simon
> Regards,
>
> Graeme
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/3] introduce nand write.trimffs
On Tue, Jun 14, 2011 at 04:35:04PM -0400, Ben Gardiner wrote: > This series adds a nand write variant which implements the procedure > reccomended in the UBI FAQ [1] of dropping trailing pages of eraseblocks > containing entirely 0xff's. > > [1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo > > Changes since v3: > * rebased to nand-flash/next where patches 1/4 and 2/4 [v3] were already >applied > * added patch 1/3 [v4] to treat WITH_YAFFS_OOB as a mode > * renumbered 3/4 and 4/4 [v3] to 1/3 and 3/3 [v4], respectively > * remove uneccessary cast > * wrapped README at 80 columns > * prevent access past input buffer end Applied to u-boot-nand-flash next -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Simon,
On Thu, Jun 16, 2011 at 7:58 AM, Simon Glass wrote:
> Hi Graeme,
>
> On Wed, Jun 15, 2011 at 1:38 PM, Graeme Russ wrote:
>> On 16/06/11 02:03, Simon Glass wrote:
>
>>> - the common case is min I think, so let's get rid of the min prefix
>>> so everyone will use it without question or needing to read screeds of
>>> doc
>>
>> I don't like this idea - Extrapolate this to dropping the 'ms' common case
>> and you end up with:
>>
>> u32 time_delta(u32 from, u32 to)
>> u32 time_delta_max(u32 from, u32 to)
>> u32 time_delta_raw(u32 from, u32 to)
>>
>> u32 time_us_delta(u32 from, u32 to)
>> u32 time_us_delta_max(u32 from, u32 to)
>> u32 time_us_delta_raw(u32 from, u32 to)
>>
>> Not as grep'able IMHO
>
> The reason I suggested this is not because it is common, in that ms is
> more common than us. It is that users will find time_ms_delta_min
> confusing. There is a min, max and raw - which should they use? While
> everyone on this list is a genius there will be other people who will
> choose one at random and run with it.
>
> To my mind 'min' is the safe one and the others will be rarely used.
>
> I agree that removing ms is a bad idea. But this is pretty grep'able
> for sensible values of grep:
>
> u32 time_delta_ms(u32 from, u32 to)
> u32 time_delta_us(u32 from, u32 to)
>
> [hide these away in the closet:
> u32 time_delta_max_ms(u32 from, u32 to)
> u32 time_delta_raw_ms(u32 from, u32 to)
> u32 time_delta_max_us(u32 from, u32 to)
> u32 time_delta_raw_us(u32 from, u32 to)
> ]
>
> int time_since_ms(u32 from)
>
> Also bear in mind that _us() will be seldom used. I will cheerfully
> use it for boot timing though.
>
> BTW should the deltas return a signed value?
No - times are unsigned utilising the entire range of the u32 so (to -
from) will always returned the unsigned delta, even if there is a wrap
between them. I cannot imagine we would ever need to measure time backward
anyway.
>>> - would prefer the ms and us at the end as I think it reads better.
>>> Getting the time is the important bit - the units are generally at the
>>> end
>>
>> Hmm, time_since_ms or time_ms_since - I suppose either reads OK - But if I
>> keep min/max/raw, I find time_min_ms_since (barely) easier in the eye than
>> time_min_since_ms - I'm not bothered either way and will go with the
>> general consensus
>
> No I mean _ms at the end, so it is always last. time_min_ms_since()
> sounds like a martian trying to learn English. See my comment above:
I read it like: Time API - Minimum Milliseconds Since (Epoch). Last time I
checked I wasn't a martian ;)
time_min_since_ms reads like: Time API - Minimum Since Millisecond (Epoch)
Anyway, time_since_ms() is fine by me
> time_since_ms() - we shouldn't even define time_since_raw_ms() and
> time_since_max_ms() in my view.
I agree that the raw versions should be dropped entirely. The max versions
should be kept (and will be used for boot profiling as you are after the
maximum time an operation could possibly have run)
>>
>>> This code from your excellent wiki page bothers me. Can we find a way
>>> to shrink it?
>>>
>>> now = timer_ms_now();
>>> if (time_ms_delta_min(start, now)> timeout)
>>>
>>> How about:
>>>
>>> if (time_since_ms(start) > timeout)
>>>
>>> The idea of the time 'since' an event is more natural than the delta
>>> between then and now which seems more abstract.
>>
>> I tend to agree - I have been thinking about 'since' functions for a while
>> now
>
> Cool.
>
>>
>> [snip]
>>
With the 'time_ms_' prefix, it's starting to get rather long, and I'm
pushing a lot of timeout checks beyond 80 columns - especially when
existing code has variables like 'start_time_tx' - I'm starting to consider
dropping the time_ prefix (all time functions will still have a ms_ or us_
prefix anyway) and rename a lot of variables
>>>
>>> Now I see why you want units at the start. Seems a bit ugly to me -
>>> which lines are getting long - do you mean the time delta check line?
>>> If so see above, or perhaps it is shorter without _min.
>>
>> An example from drivers/net/ns7520_eth.c:
>>
>> ulStartJiffies = time_ms_now();
>> while (time_ms_delta_min(ulStartJiffies, time_ms_now())
>> < NS7520_MII_NEG_DELAY) {
>>
>> Could be reduced to:
>>
>> ulStartJiffies = time_ms_now();
>> while (time_min_ms_since(ulStartJiffies) < NS7520_MII_NEG_DELAY) {
>>
>> And with a rename:
>>
>> start_ms = time_ms_now();
>> while (time_min_ms_since(start_ms) < NS7520_MII_NEG_DELAY) {
>>
>
> or:
>
> start_ms = time_now_ms();
> while (time_since_ms(start_ms) < NS7520_MII_NEG_DELAY) {
>
OK, So the API could now look like:
/* Functions to retrieve the current value of the timers */
u32 time_now_ms(void);
u32 time_now_us(void);
u64 time_now_ticks(void);
/* Functions to determine 'minimum' time elapsed (the usual case) */
u32 time_since_ms(u32 start);
u32 time_since_us(u3
[U-Boot] [PATCH] Don't do an undefined 32-bit shift on a 32-bit value for a long (4 byte) itest.l command.
Without this fix, the following statement erroneously echoed "true" (at least
on the microblaze architecture):
if itest.l 0 == 1; then echo "true"; else echo "false"; fi
(using itest.w or itest.b worked as expected even without this change)
Signed-off-by: Josh Radel
---
common/cmd_itest.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
mode change 100644 => 100755 common/cmd_itest.c
diff --git a/common/cmd_itest.c b/common/cmd_itest.c
old mode 100644
new mode 100755
index 2a238a4..5f5ac4e
--- a/common/cmd_itest.c
+++ b/common/cmd_itest.c
@@ -79,7 +79,11 @@ static long evalexp(char *s, int w)
l = simple_strtoul(s, NULL, 16);
}
- return (l & ((1 << (w * 8)) - 1));
+ if (w < sizeof(long)) {
+ return (l & ((1 << (w * 8)) - 1));
+ } else {
+ return (l);
+ }
}
static char * evalstr(char *s)
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT pull] Please pull u-boot-mpc85xx
On Jun 10, 2011, at 4:57 AM, Kumar Gala wrote: > The following changes since commit 9571865e0d32b1bcf8a6625497d1cd5d4bbad354: > > Merge branch 'master' of git://git.denx.de/u-boot-arm (2011-06-08 23:29:04 > +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-mpc85xx master > > Timur Tabi (1): > powerpc/p1022ds: set the clock-frequency prop only if the clock is > enabled > > board/freescale/p1022ds/p1022ds.c | 16 ++-- > 1 files changed, 10 insertions(+), 6 deletions(-) > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot poke. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Contact Mr. Frank Morris via email:(mrfrankmorri...@live.com) For Claims
Win $500,000 in Coca Cola Company @West Africa new year promo.To qualify,Email the correct answer to the question given below to Mr. Frank Morris via email:(mrfrankmorri...@live.com) Question: Who won the 2010 FIFA World Cup in South Africa? (A)England (B)Spain (C)Germany (D)Brazil.If you are sure kindly fill in your informations along side with the correct answer.bellow. 1) Winner Full Names: 2) Present Address: 3) Telephone Number: 4) Marital Status: 5) Age: 7) occupation: 8) Country of Residence: 9) Correct Answer: 10)Sex. 11)Nationality ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OpenRD Ultimate SATA & SD
> -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > On Behalf Of Philip Hands > Sent: Wednesday, June 15, 2011 3:24 PM > To: u-boot@lists.denx.de > Subject: [U-Boot] OpenRD Ultimate SATA & SD > > Hi, Hi Phil Thanks for the feedback. > > I've been trying to get a version of u-boot for OpenRD Ultimate that is > willing to boot from all of NAND, USB, SD and SATA, and find that SD & > SATA is still not possible with -rc1 as packaged for Debian (and it > seems that nothing in the subsequent work in the master git would help, > but if people tell me that it does, I'll give that a try). I don't know which u-boot version you are referring? Once packed with board or one from u-boot.git. For other one, u-boot.git (mainlined) SATA is functional, SD not yet supported. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Hi Grame, On Wednesday 15 June 2011 06:12 PM, Graeme Russ wrote: > On 15/06/11 22:04, Wolfgang Denk wrote: >> Dear Aneesh V, >> >> In message<4df89102.9040...@ti.com> you wrote: >>> >>> Will you accept something like this? >>> >>> a_val = (reg& a_mask)>> a_shift; >> >> Yes, of course (that's what seems most natural to me). >> > > Me too - The code is obvious - the desired value is being masked out of a > larger composite value and then shifted right to bit 0 > > And to set the value then you have: > > reg&= ~a_mask; /* Clear a_val */ > reg |= (a_val<< a_shift)& a_mask; /* Set new a_val */ > > AND'ing with a_mask is required to prevent accidental clobbering when a_val > is out-of-range. May give undesirable results by setting an illegal a_val, > but at least you don't clobber unrelated bit fields These are exactly what my helper functions were doing. Are you suggesting that doing these directly is better than doing them using helper functions? best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Graeme,
On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ wrote:
[snip]
>>
>> BTW should the deltas return a signed value?
>
> No - times are unsigned utilising the entire range of the u32 so (to -
> from) will always returned the unsigned delta, even if there is a wrap
> between them. I cannot imagine we would ever need to measure time backward
> anyway.
Can you please explain this again in different words as I don't
follow. The difference between two unsigned times may be +ve or -ve,
surely. For example, say:
now = 100
event_time = 200
then the delta is currently -100. Some people might loop until the
delta is >= 0. This is like setting a future time and waiting for it
to happen. If the delta is unsigned then this won't work.
>> No I mean _ms at the end, so it is always last. time_min_ms_since()
>> sounds like a martian trying to learn English. See my comment above:
>
> I read it like: Time API - Minimum Milliseconds Since (Epoch). Last time I
> checked I wasn't a martian ;)
I see. I wonder how you checked? Skin color and height I suppose.
>
> time_min_since_ms reads like: Time API - Minimum Since Millisecond (Epoch)
>
> Anyway, time_since_ms() is fine by me
>
>> time_since_ms() - we shouldn't even define time_since_raw_ms() and
>> time_since_max_ms() in my view.
>
> I agree that the raw versions should be dropped entirely. The max versions
> should be kept (and will be used for boot profiling as you are after the
> maximum time an operation could possibly have run)
OK I wasn't suggesting dropping raw, just hiding it. My main point was
just that the common one should have the obvious name. Anyway, I
suppose raw is not that useful.
>
>>>
This code from your excellent wiki page bothers me. Can we find a way
to shrink it?
now = timer_ms_now();
if (time_ms_delta_min(start, now)> timeout)
How about:
if (time_since_ms(start) > timeout)
The idea of the time 'since' an event is more natural than the delta
between then and now which seems more abstract.
>>>
>>> I tend to agree - I have been thinking about 'since' functions for a while
>>> now
>>
>> Cool.
>>
>>>
>>> [snip]
>>>
>
> With the 'time_ms_' prefix, it's starting to get rather long, and I'm
> pushing a lot of timeout checks beyond 80 columns - especially when
> existing code has variables like 'start_time_tx' - I'm starting to
> consider
> dropping the time_ prefix (all time functions will still have a ms_ or us_
> prefix anyway) and rename a lot of variables
Now I see why you want units at the start. Seems a bit ugly to me -
which lines are getting long - do you mean the time delta check line?
If so see above, or perhaps it is shorter without _min.
>>>
>>> An example from drivers/net/ns7520_eth.c:
>>>
>>> ulStartJiffies = time_ms_now();
>>> while (time_ms_delta_min(ulStartJiffies, time_ms_now())
>>> < NS7520_MII_NEG_DELAY) {
>>>
>>> Could be reduced to:
>>>
>>> ulStartJiffies = time_ms_now();
>>> while (time_min_ms_since(ulStartJiffies) < NS7520_MII_NEG_DELAY) {
>>>
>>> And with a rename:
>>>
>>> start_ms = time_ms_now();
>>> while (time_min_ms_since(start_ms) < NS7520_MII_NEG_DELAY) {
>>>
>>
>> or:
>>
>> start_ms = time_now_ms();
>> while (time_since_ms(start_ms) < NS7520_MII_NEG_DELAY) {
>>
>
> OK, So the API could now look like:
>
> /* Functions to retrieve the current value of the timers */
> u32 time_now_ms(void);
> u32 time_now_us(void);
> u64 time_now_ticks(void);
>
> /* Functions to determine 'minimum' time elapsed (the usual case) */
> u32 time_since_ms(u32 start);
> u32 time_since_us(u32 start);
> u64 time_since_us(u64 start);
time_since_ticks()
>
> /* Functions to determine 'maximum' time elapsed (performance profiling) */
> u32 time_max_since_ms(u32 start);
> u32 time_max_since_us(u32 start);
> u64 time_max_since_ticks(u64 start);
>
> /* Default udelay() */
> void udelay(u32 delay)
> {
> u32 start = time_now_us();
>
> while(time_since_us(start) < delay)
> ;
> }
Well it has my vote - does it solve your 80-column problems? Some
might complain about the proliferation of 'since' functions. I don't
have a strong view on this - but it is perhaps preferable to having
everyone do things manually. The strongly orthogonal nature of your
functions helps with understanding anyway I think.
One interesting aspect to me is whether it might be possible for the
'since' functions to have a debug mode which prints out a message when
the boot appears to be hung. Sometimes U-Boot hangs on USB or similar
and there is no message displayed. I imagine it might be possible to
detect a hung or repeating timeout and print a stack trace. Another
thing is how much time was spent hanging around during a boot (as a
summary at the end). Just a thought, and NOT suggesting doing
anything about it now.
Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros
Hi Aneesh,
On Thu, Jun 16, 2011 at 3:39 PM, Aneesh V wrote:
> Hi Grame,
>
> On Wednesday 15 June 2011 06:12 PM, Graeme Russ wrote:
>>
>> On 15/06/11 22:04, Wolfgang Denk wrote:
>>>
>>> Dear Aneesh V,
>>>
>>> In message<4df89102.9040...@ti.com> you wrote:
Will you accept something like this?
a_val = (reg& a_mask)>> a_shift;
>>>
>>> Yes, of course (that's what seems most natural to me).
>>>
>>
>> Me too - The code is obvious - the desired value is being masked out of a
>> larger composite value and then shifted right to bit 0
>>
>> And to set the value then you have:
>>
>> reg&= ~a_mask; /* Clear a_val */
>> reg |= (a_val<< a_shift)& a_mask; /* Set new a_val */
>>
>> AND'ing with a_mask is required to prevent accidental clobbering when
>> a_val
>> is out-of-range. May give undesirable results by setting an illegal a_val,
>> but at least you don't clobber unrelated bit fields
>
> These are exactly what my helper functions were doing. Are you
> suggesting that doing these directly is better than doing them
> using helper functions?
I (personally) think that the two lines of memberwise bit mask/shift is
more obvious in its intent that even clrsetbits. I understand there is
defensive programming issues that can be applied with macros or helper
functions, but then the you loose 'obviousness' and sometimes this can
make figuring out the problem even harder (one assumes the macro or
helper function works properly).
When push comes to shove, the compiler will probably produce identical
code anyway.
Sometimes I like seeing the raw elegance of what is going on under the
hood :)
Now, that being said, I see no reason not to do the following if I had,
for example, multiple serial port configuration registers which are all
identical:
/* num data bits is stored in bits 2-4 of the serial config register */
#define DATA_BITS_MASK 0x001c
#define DATA_BITS_OFFSET2
u32 set_serial_data_bits(u32 ser_cfg, u8 data_bits)
{
ser_cfg &= ~DATA_BITS_MASK;
ser_cfg |= ((u32)ser_cfg << DATA_BITS_OFFSET) & DATA_BITS_MASK;
return ser_cfg;
}
void serial_init(void)
{
u32 ser_cfg;
for (i=0; ihttp://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details
Hi Simon, On Thu, Jun 16, 2011 at 3:53 PM, Simon Glass wrote: > Hi Graeme, > > On Wed, Jun 15, 2011 at 4:09 PM, Graeme Russ wrote: > [snip] >>> >>> BTW should the deltas return a signed value? >> >> No - times are unsigned utilising the entire range of the u32 so (to - >> from) will always returned the unsigned delta, even if there is a wrap >> between them. I cannot imagine we would ever need to measure time backward >> anyway. > > Can you please explain this again in different words as I don't > follow. The difference between two unsigned times may be +ve or -ve, > surely. For example, say: > > now = 100 > event_time = 200 > > then the delta is currently -100. Some people might loop until the > delta is >= 0. This is like setting a future time and waiting for it > to happen. If the delta is unsigned then this won't work. > start = 0xff00 now = 0x0010 So there was a timer wrap between 'start' and 'now' delta = now - start = 0x110 Remember that the new timer API does not rely on the tick counter (and therefore the ms/us timers) to start at zero - It must be allowed to wrap without causing timer glitches at any arbitray time Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
