Re: [U-Boot] Driver for CONFIG_CF_QSPI
Richard, The QSPI driver can be found in MCF5329 LTIB. Regards, TC On Mon, 2010-07-26 at 16:33 -0400, Richard Retanubun wrote: > Hi TC, > > I am looking to use the QSPI for MCF5270 and noticed that the cf_spi driver > only stubs this part. > Any chance there are CF_QSPI driver code written somewhere but just not > submitted upstream? > Sorry for overloading the question, any pointers to where I can find it for > uClinux also? > > Thanks for your time > > - Richard Retanubun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash
On 2010/08/24 8:07 AM, Albert ARIBAUD wrote: > Le 24/08/2010 07:21, Chris Moore a écrit : >> Hi Rogan, >> >> Le 23/08/2010 18:06, Rogan Dawes a écrit : >>> Doubling the value for ORION5X_SZ_BOOTROM allowed me to access the >>> additional sectors, but that makes me wonder what the reason for it is. >>> >>> I know that the flash chip is wired up strangely, but would that also >>> affect the window mappings? If that is the case, I just need to document >>> WHY the parameter is doubled, but if not, it would be good to understand >>> the real reason for the change. >>> >> >> I am (very rashly) stabbing in the dark here because I don't know much >> about U-Boot and I haven't followed your previous posts (hence this >> off-list reply). >> >> However if your device size is half the bus size (like an 8-bit device >> on a 16-bit bus) it would seem logical to have to double the window size. >> >> Cheers, >> Chris > > Hi Chris, BTW. :) > > Rogan, > > Seeing as ORION5X_SZ_BOOTROM is only used as a byte address limit for > window mapping, and device vs bus size govern the maximum amout in a > single bus access but do not govern its addressing, I don't think device > width is involved here. > > I'd rather ask whether this could be a window alignment issue, i.e is > the flash base address 8 MB aligned? Seems like it, because IIRC its > base is FF80, which is 8MB-aligned. > > Can you still try the original u-boot? Does it allow reading the full 8 > MB? If so, can you do a 'md.l 0xF102 40' in it, and then in your own > u-boot with ORION5X_SZ_BOOTROM set to 8MB then 16MB? These are the > window mapping registers, and it will allow us to know what the CPU > really thinks boot ROM looks like. Also dump F101046C, that's the boot > device bus configuration, again in both U-boots. > > Amicalement, Hi Albert, Yes, I still have the vendor u-boot flashed, so I can still see its configuration. And, yes, it does allow reading the full 8MB of flash. Vendor u-boot: > md.l f102 40 f102: 07ff5941 9000 4000 ay.@ f1020010: 07ff5931 9800 4000 1y.@ f1020020: 000f5141 f000 AQ.. f1020030: 000f5131 f010 1Q.. f1020040: 007f0f11 ff80 f1020050: 001f1e11 fa00 f1020060: 01ff1d11 f800 f1020070: 000f1b11 fa80 f1020080: f100 f1020090: f10200a0: f10200b0: f10200c0: f10200d0: f10200e0: f10200f0: Mainline (8MB window): > md.l f102 40 f102: 03ff5941 9000 9000 AY.. f1020010: 5141 f000 9000 AQ.. f1020020: 03ff5931 9800 1Y.. f1020030: 5131 f010 1Q.. f1020040: 000f1e11 fa00 f1020050: 00ff1d11 f800 f1020060: 00071b11 fa80 f1020070: 003f0f11 ff80 ..?. f1020080: f100 f1020090: f10200a0: f10200b0: f10200c0: f10200d0: f10200e0: f10200f0: Mainline (16MB window): > md.l f102 40 f102: 03ff5941 9000 9000 AY.. f1020010: 5141 f000 9000 AQ.. f1020020: 03ff5931 9800 1Y.. f1020030: 5131 f010 1Q.. f1020040: 000f1e11 fa00 f1020050: 00ff1d11 f800 f1020060: 00071b11 fa80 f1020070: 007f0f11 ff80 f1020080: f100 f1020090: f10200a0: f10200b0:
[U-Boot] [PATCH] ARMV7: S5P: fix the macro at samsung_get_base function
New line is unnecessary at last line of macro. Signed-off-by: Minkyu Kang --- arch/arm/include/asm/arch-s5pc1xx/cpu.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/include/asm/arch-s5pc1xx/cpu.h b/arch/arm/include/asm/arch-s5pc1xx/cpu.h index 0e80ba3..e74959f 100644 --- a/arch/arm/include/asm/arch-s5pc1xx/cpu.h +++ b/arch/arm/include/asm/arch-s5pc1xx/cpu.h @@ -85,7 +85,7 @@ static inline unsigned int samsung_get_base_##device(void) \ return S5PC110_##base; \ else\ return 0; \ -} \ +} SAMSUNG_BASE(clock, CLOCK_BASE) SAMSUNG_BASE(gpio, GPIO_BASE) -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Invitation to connect on LinkedIn
LinkedIn yefeng fan requested to add you as a connection on LinkedIn: -- Srinath, I'd like to add you to my professional network on LinkedIn. - yefeng Accept invitation from yefeng fan http://www.linkedin.com/e/fds2np-gd8g6huf-1q/YhLefj14Y3m-0E8v1ZCDgtixJP5Kn9_7/blk/I2287545393_2/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYOnPcVcPkQdjsUcz99bQRxiDlktAtCbPAVd30McPgVdj4LrCBxbOYWrSlI/EML_comm_afe/ View invitation from yefeng fan http://www.linkedin.com/e/fds2np-gd8g6huf-1q/YhLefj14Y3m-0E8v1ZCDgtixJP5Kn9_7/blk/I2287545393_2/39vcPAPdjgRdPwOcAALqnpPbOYWrSlI/svi/ -- (c) 2010, LinkedIn Corporation___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMV7: S5P: separate the peripheral clocks
Because of peripheral devices can select clock sources,
separate the peripheral clocks. (pwm, uart and so on)
It just return the pclk at s5pc1xx SoC,
but s5pc210 SoC must be calculated by own clock register setting.
Signed-off-by: Minkyu Kang
Signed-off-by: Kyungmin Park
---
arch/arm/cpu/armv7/s5p-common/timer.c |4 ++--
arch/arm/cpu/armv7/s5pc1xx/clock.c | 25 ++---
arch/arm/include/asm/arch-s5pc1xx/clk.h |3 ++-
drivers/serial/serial_s5p.c |4 ++--
4 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/s5p-common/timer.c
b/arch/arm/cpu/armv7/s5p-common/timer.c
index 1f1c7ff..0490650 100644
--- a/arch/arm/cpu/armv7/s5p-common/timer.c
+++ b/arch/arm/cpu/armv7/s5p-common/timer.c
@@ -57,7 +57,7 @@ int timer_init(void)
/*
* @ PWM Timer 4
* Timer Freq(HZ) =
-* PCLK / { (prescaler_value + 1) * (divider_value) }
+* PWM_CLK / { (prescaler_value + 1) * (divider_value) }
*/
/* set prescaler : 16 */
@@ -68,7 +68,7 @@ int timer_init(void)
if (count_value == 0) {
/* reset initial value */
/* count_value = 2085937.5(HZ) (per 1 sec)*/
- count_value = get_pclk() / ((PRESCALER_1 + 1) *
+ count_value = get_pwm_clk() / ((PRESCALER_1 + 1) *
(MUX_DIV_2 + 1));
/* count_value / 100 = 20859.375(HZ) (per 10 msec) */
diff --git a/arch/arm/cpu/armv7/s5pc1xx/clock.c
b/arch/arm/cpu/armv7/s5pc1xx/clock.c
index c9b5485..98a27e5 100644
--- a/arch/arm/cpu/armv7/s5pc1xx/clock.c
+++ b/arch/arm/cpu/armv7/s5pc1xx/clock.c
@@ -38,7 +38,8 @@
#define CONFIG_SYS_CLK_FREQ_C110 2400
#endif
-unsigned long (*get_pclk)(void);
+unsigned long (*get_uart_clk)(int dev_index);
+unsigned long (*get_pwm_clk)(void);
unsigned long (*get_arm_clk)(void);
unsigned long (*get_pll_clk)(int);
@@ -297,15 +298,33 @@ static unsigned long s5pc100_get_pclk(void)
return get_pclkd1();
}
+/* s5pc1xx: return uart clock frequency */
+static unsigned long s5pc1xx_get_uart_clk(int dev_index)
+{
+ if (cpu_is_s5pc110())
+ return s5pc110_get_pclk();
+ else
+ return s5pc100_get_pclk();
+}
+
+/* s5pc1xx: return pwm clock frequency */
+static unsigned long s5pc1xx_get_pwm_clk(void)
+{
+ if (cpu_is_s5pc110())
+ return s5pc110_get_pclk();
+ else
+ return s5pc100_get_pclk();
+}
+
void s5p_clock_init(void)
{
if (cpu_is_s5pc110()) {
get_pll_clk = s5pc110_get_pll_clk;
get_arm_clk = s5pc110_get_arm_clk;
- get_pclk = s5pc110_get_pclk;
} else {
get_pll_clk = s5pc100_get_pll_clk;
get_arm_clk = s5pc100_get_arm_clk;
- get_pclk = s5pc100_get_pclk;
}
+ get_uart_clk = s5pc1xx_get_uart_clk;
+ get_pwm_clk = s5pc1xx_get_pwm_clk;
}
diff --git a/arch/arm/include/asm/arch-s5pc1xx/clk.h
b/arch/arm/include/asm/arch-s5pc1xx/clk.h
index c25e17a..3488eb7 100644
--- a/arch/arm/include/asm/arch-s5pc1xx/clk.h
+++ b/arch/arm/include/asm/arch-s5pc1xx/clk.h
@@ -33,6 +33,7 @@ void s5p_clock_init(void);
extern unsigned long (*get_pll_clk)(int pllreg);
extern unsigned long (*get_arm_clk)(void);
-extern unsigned long (*get_pclk)(void);
+extern unsigned long (*get_pwm_clk)(void);
+extern unsigned long (*get_uart_clk)(int dev_index);
#endif
diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
index 6a61b4f..7709664 100644
--- a/drivers/serial/serial_s5p.c
+++ b/drivers/serial/serial_s5p.c
@@ -63,11 +63,11 @@ void serial_setbrg_dev(const int dev_index)
{
DECLARE_GLOBAL_DATA_PTR;
struct s5p_uart *const uart = s5p_get_base_uart(dev_index);
- u32 pclk = get_pclk();
+ u32 uclk = get_uart_clk(dev_index);
u32 baudrate = gd->baudrate;
u32 val;
- val = pclk / baudrate;
+ val = uclk / baudrate;
writel(val / 16 - 1, &uart->ubrdiv);
writew(udivslot[val % 16], &uart->udivslot);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] SPI: cmd_spi.c: add option to specify bus and mode
Dear Mike Frysinger, > were you going to send an updated version ? Soon. Currently I have other issues and a rather "dirty" working tree :) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] i.mx51 nand boot.
hi,all: I want to use i.MX51 base board to booting u-boot from nand flash,how can I do? thanks best regards shulin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non-experimental U-Boot compilation
Dear sandeep suresh, > Dear Reinhard Meyer, > Appreciate your quick response. I had done this earlier > before posting this mail, but with the same problem: > step 1) export PATH=$PATH:/work/arm/4.3.2/bin > step 2) make distclean > step 3) make AT91SAM9260ek_config > step 4)make > Can you please help me further, please. I can't help you with the following tasks: 1. find out what are the differences between 9260-EK and 9G20-EK ? 2. find out what subtle differences might exist between 9260 and 9G20 SoC? It might be more than "AT91SAM9G20 = 400MHz version of AT91SAM9260"... And I can't see in above transcript where you set the #define I mentioned. "#ifdef CONFIG_AT91SAM9G20EK" exists in various places in the source, but I do not know if that ever was a really working port or just someone starting on it. Reinhard PS: it is mandatory to post replies to the mailing list as well! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Booting from Nand based on i.MX51
Hi, I am using mx51 base board, I want to make u-boot booting from nand flash. Does anyone knows how to modify the u-boot source? Does add some code to init the nand flash controller in flash_header.S's dcd section? Does anyone have u-boot booting from NAND on mx51? Any repository, or a patch that might be available? Best Regards, Shulin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Booting from Nand Flash base on i.MX51.
Hi, I am using mx51 base board, I want to make u-boot booting from nand flash. Does anyone knows how to modify the u-boot source? Does add some code to init the nand flash controller in flash_header.S's dcd section? Does anyone have u-boot booting from NAND on mx51? Any repository, or a patch that might be available? Best Regards, Shulin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non-experimental U-Boot compilation
Dear Reinhard Meyer & All, Apology for not sending to the mailing list; forwarding the same to the mailing list. There is already a #define CONFIG_AT91SAM9260ek 1 in /include/configs/at91sam9260ek.h. I will check further. Please help me if you have any clue further. Thanks & regards Sandeep Suresh. From: Reinhard Meyer To: sandeep suresh ; u-boot Sent: Tue, 24 August, 2010 1:50:24 PM Subject: Re: [U-Boot] Non-experimental U-Boot compilation Dear sandeep suresh, > Dear Reinhard Meyer, > Appreciate your quick response. I had done this earlier > before posting this mail, but with the same problem: > step 1) export PATH=$PATH:/work/arm/4.3.2/bin > step 2) make distclean > step 3) make AT91SAM9260ek_config > step 4)make > Can you please help me further, please. I can't help you with the following tasks: 1. find out what are the differences between 9260-EK and 9G20-EK ? 2. find out what subtle differences might exist between 9260 and 9G20 SoC? It might be more than "AT91SAM9G20 = 400MHz version of AT91SAM9260"... And I can't see in above transcript where you set the #define I mentioned. "#ifdef CONFIG_AT91SAM9G20EK" exists in various places in the source, but I do not know if that ever was a really working port or just someone starting on it. Reinhard PS: it is mandatory to post replies to the mailing list as well! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non-experimental U-Boot compilation
Dear sandeep suresh, > Dear Reinhard Meyer & All, >Apology for not sending to the mailing list; forwarding > the same to the mailing list. There is already a #define > CONFIG_AT91SAM9260ek 1 in /include/configs/at91sam9260ek.h. I will check > further. #define CONFIG_AT91SAM9G20EK !!! I think you would have to define this additionally to or instead of. If that does not help, you have to investigate yourself what the diffeences are. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting from Nand Flash base on i.MX51.
shulin.zhou wrote: > Hi, > Hi, > I am using mx51 base board, I want to make u-boot booting from nand flash. > Does anyone knows how to modify the u-boot source? You have to add support for the NAND controller, not yet in mainline. > > Does add some code to init the nand flash controller in > flash_header.S's dcd section? You are not talking about u-boot sources in mainline. Linking the DCD together with u-boot is the original development by Freescale. There is no flash_header.S in u-boot. In mainline, an header is added to the binary providing a different image that can be loaded into the storage. See doc/README.imximage. This is consistent in u-boot because other processors use the same approach. > Does anyone have u-boot booting from NAND on mx51? Any repository, or a > patch that might be available? At the moment, NAND is not supported in u-boot mainline for the MX.51. Patches are welcome ;-) 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] Add generic support for samsung s3c2440
Dear C Nauman,
On 23 August 2010 22:40, C Nauman wrote:
> This patch adds generic support for the Samsung s3c2440 processor.
> Started from patch posted 2009-06-19 by
> Kevin Morfitt. Then modified for changes in the code that have occurred
> since.
>
> Signed-off-by: Craig Nauman diagraph.com>
Please fix the email address.
And could you please use the git format-patch?
so that we can see what are changed.
> ---
>
> diff --git a/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
> b/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
> index 15f53dd..d4abd24 100644
> --- a/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
> +++ b/arch/arm/include/asm/arch-s3c24x0/s3c24x0.h
> @@ -82,6 +82,10 @@ struct s3c24x0_interrupt {
> u32 SUBSRCPND;
> u32 INTSUBMSK;
> #endif
> +#ifdef CONFIG_S3C2440
> + u32 SUBSRCPND;
> + u32 INTSUBMSK;
> +#endif
> };
We don't allow upper case structure members.
That is reason for why kevin sent clean-up patches.
Please fix it globally.
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] SPI: cmd_spi.c: add option to specify bus and mode
Dear Mike Frysinger, > this usage string no longer makes sense. how about: > "[:][.] - Send bits from > out the SPI\n" The problem is, that without blowing up the parser even more, only 2 forms of the command are valid: the classic form or :[.] Since this command is mainly used for testing/debugging hardware, I saw no need to allow the form . If thats ok, I can make a patch with the help fixed. Best Regards Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash
Le 24/08/2010 09:47, Rogan Dawes a écrit : > Yes, I still have the vendor u-boot flashed, so I can still see its > configuration. And, yes, it does allow reading the full 8MB of flash. > Vendor u-boot: > f1020040: 007f0f11 ff80 > Mainline (8MB window): > f1020070: 003f0f11 ff80 ..?. > Mainline (16MB window): > f1020070: 007f0f11 ff80 The good news is that your flash works normally. The bad news is that the mainline settings you are showing here are wrong with respect to the ORION5X_SZ_BOOTROM: A 16 MB window would be 00ff0f11. 007f0f11 is 8MB, and 003f0f11 is 4 MB. Thus, what you think is a 16MB widow is actually a 8MB one, and the 8MB one is actually 4MB, which explains the issues you have. I've just checked the code for computing the window size in mainline u-boot, and it is off by one, reducing the actual window mapping by half. :( They weird thing is that it affect *all* windows, RAM included; we should have seen other issues! I'll do some checks later today and provide an officiel bugfix this evening. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] [TESTING] da8xx: fixup ARM relocation support
Hi,
On Mon, Aug 23, 2010 at 18:38:15, Ben Gardiner wrote:
> Split the existing dram_init for da8xx when ARM reloc is enabled, like the
> changes to arch/arm/cpu/arm926ejs/orion5x/dram.c in
> 0f234d263b17ccf1b8fd776eb8c15b7cdb27a887 by Heiko Schocher .
>
> Without these changes gd->ram_size is '0' which leads to incorrect relocation
> when CONFIG_SYS_ARM_WITHOUT_RELOC is defined and the board does not boot.
>
> We use get_ram_size to dynamically calculate the available RAM because it runs
> on different board version with different ram, as suggested by Heiko in
> private
> communication.
>
> Tested on a da850evm with 128M of DDR2 installed; with both
> CONFIG_SYS_ARM_WITHOUT_RELOC defined and undefined.
>
> Signed-off-by: Ben Gardiner
> CC: Sudhakar Rajashekhara
> CC: Heiko Schocher
> ---
> This patch is submitted for the arm-reloc-and-cache-support branch of
> git://git.denx.de/u-boot-testing.git
>
> V2:
> * added Nori Sehkar to the to: list
> * indicated for which branch of testing this patch is submitted.
>
> V3:
> * fix checkpatch errors
> * directed to Sudhakar Rajashekhara instead of Nori Sehkar
> ---
> board/davinci/common/misc.c | 17 +
> include/configs/da850evm.h |1 +
> 2 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c
> index 25ca326..86a875e 100644
> --- a/board/davinci/common/misc.c
> +++ b/board/davinci/common/misc.c
> @@ -33,6 +33,7 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
> int dram_init(void)
> {
> gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> @@ -40,6 +41,22 @@ int dram_init(void)
>
> return(0);
> }
> +#else
> +int dram_init(void)
> +{
> + /* dram_init must store complete ramsize in gd->ram_size */
> + gd->ram_size = get_ram_size(
> + (volatile void *)CONFIG_SYS_SDRAM_BASE,
> + CONFIG_MAX_RAM_BANK_SIZE);
> + return 0;
> +}
> +
> +void dram_init_banksize(void)
> +{
> + gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> + gd->bd->bi_dram[0].size = gd->ram_size;
> +}
> +#endif
>
> #ifdef CONFIG_DRIVER_TI_EMAC
>
> diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
> index 016a21e..d02b196 100644
> --- a/include/configs/da850evm.h
> +++ b/include/configs/da850evm.h
> @@ -47,6 +47,7 @@
> #define CONFIG_SYS_GBL_DATA_SIZE 128 /* reserved for initial data */
> #define PHYS_SDRAM_1 DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */
> #define PHYS_SDRAM_1_SIZE(64 << 20) /* SDRAM size 64MB */
> +#define CONFIG_MAX_RAM_BANK_SIZE (512 << 20) /* max size from SPRS586*/
>
> /* memtest start addr */
> #define CONFIG_SYS_MEMTEST_START (PHYS_SDRAM_1 + 0x200)
Reviewed-by: Sudhakar Rajashekhara
Thanks,
Sudhakar
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash
On 2010/08/24 1:34 PM, Albert ARIBAUD wrote: > Le 24/08/2010 09:47, Rogan Dawes a écrit : > >> Yes, I still have the vendor u-boot flashed, so I can still see its >> configuration. And, yes, it does allow reading the full 8MB of flash. > >> Vendor u-boot: > >> f1020040: 007f0f11 ff80 > >> Mainline (8MB window): > >> f1020070: 003f0f11 ff80 ..?. > >> Mainline (16MB window): > >> f1020070: 007f0f11 ff80 > > The good news is that your flash works normally. > > The bad news is that the mainline settings you are showing here are > wrong with respect to the ORION5X_SZ_BOOTROM: A 16 MB window would be > 00ff0f11. 007f0f11 is 8MB, and 003f0f11 is 4 MB. Thus, what you think is > a 16MB widow is actually a 8MB one, and the 8MB one is actually 4MB, > which explains the issues you have. > > I've just checked the code for computing the window size in mainline > u-boot, and it is off by one, reducing the actual window mapping by > half. :( > > They weird thing is that it affect *all* windows, RAM included; we > should have seen other issues! I'll do some checks later today and > provide an officiel bugfix this evening. > > Amicalement, Hi Albert, Thanks for looking at this. Do you mean that your own u-boot is also misconfigured? Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash
Le 24/08/2010 14:17, Rogan Dawes a écrit : > On 2010/08/24 1:34 PM, Albert ARIBAUD wrote: >> Le 24/08/2010 09:47, Rogan Dawes a écrit : >> >>> Yes, I still have the vendor u-boot flashed, so I can still see its >>> configuration. And, yes, it does allow reading the full 8MB of flash. >> >>> Vendor u-boot: >> >>> f1020040: 007f0f11 ff80 >> >>> Mainline (8MB window): >> >>> f1020070: 003f0f11 ff80 ..?. >> >>> Mainline (16MB window): >> >>> f1020070: 007f0f11 ff80 >> >> The good news is that your flash works normally. >> >> The bad news is that the mainline settings you are showing here are >> wrong with respect to the ORION5X_SZ_BOOTROM: A 16 MB window would be >> 00ff0f11. 007f0f11 is 8MB, and 003f0f11 is 4 MB. Thus, what you think is >> a 16MB widow is actually a 8MB one, and the 8MB one is actually 4MB, >> which explains the issues you have. >> >> I've just checked the code for computing the window size in mainline >> u-boot, and it is off by one, reducing the actual window mapping by >> half. :( >> >> They weird thing is that it affect *all* windows, RAM included; we >> should have seen other issues! I'll do some checks later today and >> provide an officiel bugfix this evening. >> >> Amicalement, > > Hi Albert, > > Thanks for looking at this. > > Do you mean that your own u-boot is also misconfigured? > > Rogan Yes, it is, to the point that just like you, I can only flash the lower half of my (512KB) flash -- when I did the flash tests, it escaped me because I only erased and flashed small sectors at the beginning of the flash. :/ As for RAM, thanks to Wolfgang's suggestion to use get_ram_size() rather than the (now evidently buggy) SoC's calculation routine, mainline u-boot actually finds the real amount of RAM regardless of any macro value, which explains why u-boot could access RAM above the first half, and especially the upmost megabyte as I am doing now. Bugfix patch on its way, and adding Prafulla as this bug also hits kirkwood SoC code from which the calculation code was taken. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Non-experimental U-Boot compilation
Hi, > Dear all, > I am using the AT91SAM9G20EK kit and want to port Linux on this. Actually Atmel has already done this, see http://www.linux4sam.org > the AT91SAM9260ek configuration as it seems the closest. The problem is after > building the U-boot with the sources for this board, generating the .bin, > loading and a power on reset (POR), there isn't a command prompt exposed > (u-boot>). After POR, 1 1 2 1 1 2 continuosly prints on the hyperterminal. I > read from AT91.com that this is the expected behavior for the demo version. Yes, this is the expected behaviour for the demo package. When you see this, it means you do not boot from the media where you burn your U-Boot into. > What is rge procedure to get the prompt ? Are there any separate > configuration > settings? AT91SAM9G20EK are well supported by both mainline code and Atmel's current binary. ( u-boot 1.3.4, a little bit old) For detailed steps to run U-Boot/Linux on your board, still, goto http://www.linux4sam.org BR, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Orion5x: bugfix: window size (mis)calculation
Fix orion5x_winctrl_calcsize() off-by-1 bug which caused mapping
windows to be cut by half. This afected all windows including NOR
flash (causing half the flash to be unaccessible) but DRAM was and
still is fine as its size is determined otherwise.
Signed-off-by: Albert Aribaud
---
arch/arm/cpu/arm926ejs/orion5x/cpu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/orion5x/cpu.c
b/arch/arm/cpu/arm926ejs/orion5x/cpu.c
index 3740e33..260f88b 100644
--- a/arch/arm/cpu/arm926ejs/orion5x/cpu.c
+++ b/arch/arm/cpu/arm926ejs/orion5x/cpu.c
@@ -61,7 +61,7 @@ unsigned int orion5x_winctrl_calcsize(unsigned int sizeval)
unsigned int j = 0;
u32 val = sizeval >> 1;
- for (i = 0; val > 0x1; i++) {
+ for (i = 0; val >= 0x1; i++) {
j |= (1 << i);
val = val >> 1;
}
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the MPC5121e USB Host controller.
Hi Damien this patch seems to be doing alot better then the original one. The root hub is detected and also it detects a device connected to the controller. However, by testing with a usbstick (mass storage) it fails to detect the device as a storage device. I have here a debug printout which is being printed (with debug enabled) during execution of the command 'usb start': - => usb start (Re)start USB... Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... New Device 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x19 get_conf_no 0 Result 25, wLength 25 if 0, ep 0 ##EP epmaxpacketin[1] = 2048 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=1, Product=2, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 1 default language ID 0x1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 length 0xFF Manufacturer u-boot Product EHCI Host Controller SerialNumber USB hub found usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x8 1 ports detected ganged power switching standalone hub global over-current protection power on to power good time: 510ms hub controller current requirement: 0mA port 1 is not removable usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 get_hub_status returned status 1, change 1 local power source is lost (inactive) no over-current condition exists enabling power on all ports usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 Port 1 Status 101 Change 1 port 1 connection change usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 101, change 1, 12 Mb/s usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0 hub_port_reset: resetting port 0... usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 503, change 10, 480 Mb/s STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 New Device 1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 hub_port_reset: resetting port 0... usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 503, change 10, 480 Mb/s STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 set address 2 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x19 get_conf_no 0 Result 25, wLength 25 if 0, ep 0 ##EP epmaxpacketin[1] = 1 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=0, Product=0, SerialNumber=0 Manufacturer Product SerialNumber USB hub found usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x9 4 ports detected individual port power switching standalone hub individual port over-current protection power on to power good time: 100ms hub controller current requirement: 100mA port 1 is removable port 2 is removable port 3 is removable port 4 is removable usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 get_hub_status returned status 0, change 0 local power source is good no over-current condition exists enabling power on all ports usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x2 length 0x0 port 2 returns 0 usb_control_msg: request: 0x3, requesttype: 0x23, va
Re: [U-Boot] [PATCH] MTD: Add support for S25FL032P spi nor-flash
On Tuesday, August 24, 2010 02:39:16 David Jander wrote:
> On Monday 23 August 2010 06:31:26 pm Mike Frysinger wrote:
> > On Monday, August 23, 2010 09:12:16 David Jander wrote:
> > > + {
> > > + .idcode1 = SPSN_ID_S25FL032A,
> > > + .idcode2 = SPSN_EXT_ID_S25FL032P,
> > > + .idmask2 = 0xff00,
> >
> > what does the idcode2 look like such that you need a mask ?
>
> According to the datasheet the RDID command (0x9f) returns the following
> bytes:
>
> byte 0: Manufacturer ID = 0x01
> byte 1,2: Device ID = 0x02, 0x15 (same as S25FL032A)
> byte 3: Extended ID = 0x4d
> byte 4,5,6: Spansion reserved (do not use).
>
> byte 4 is read as 0x00 on my part, but due to the above explaination, I
> cannot say for sure it is always the same, so I had to implement a mask to
> check for it.
i'd rather we delay adding code to support something that may never change.
so drop the whole idmask2 stuff and wait for it to become an actual problem
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT91: fix at91sam9260.h for AT91SAM9XE
For some reason Atmel changed the GPBR address for the AT91SAM9XE to be different from the engineering samples and the AT91SAM9260. Also let the correct SoC name be defined. Signed-off-by: Reinhard Meyer --- arch/arm/include/asm/arch-at91/at91sam9260.h | 19 +++ 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/arch/arm/include/asm/arch-at91/at91sam9260.h b/arch/arm/include/asm/arch-at91/at91sam9260.h index ec04318..91ea800 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9260.h +++ b/arch/arm/include/asm/arch-at91/at91sam9260.h @@ -59,7 +59,16 @@ #define AT91_RTT_BASE 0xfd20 #define AT91_PIT_BASE 0xfd30 #define AT91_WDT_BASE 0xfd40 -#define AT91_GPR_BASE 0xfd50 +/* + * The latest revision of the AT91SAM9XE has the GPBR moved up 0x10. + * (its not a bug, its a feature...) + * Maybe we can figure a dynamic way to handle this later... + */ +#ifdef CONFIG_AT91SAM9XE +# define AT91_GPR_BASE 0xfd60 +#else +# define AT91_GPR_BASE 0xfd50 +#endif #ifdef CONFIG_AT91_LEGACY @@ -140,10 +149,12 @@ /* * Cpu Name */ -#if defined(CONFIG_AT91SAM9260) -#define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9260" +#if defined(CONFIG_AT91SAM9XE) +# define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9XE" +#elif defined(CONFIG_AT91SAM9260) +# define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9260" #elif defined(CONFIG_AT91SAM9G20) -#define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9G20" +# define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9G20" #endif #endif -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: Add support for S25FL032P spi nor-flash
On Tuesday 24 August 2010 06:06:26 pm Mike Frysinger wrote:
> On Tuesday, August 24, 2010 02:39:16 David Jander wrote:
> > On Monday 23 August 2010 06:31:26 pm Mike Frysinger wrote:
> > > On Monday, August 23, 2010 09:12:16 David Jander wrote:
> > > > + {
> > > > + .idcode1 = SPSN_ID_S25FL032A,
> > > > + .idcode2 = SPSN_EXT_ID_S25FL032P,
> > > > + .idmask2 = 0xff00,
> > >
> > > what does the idcode2 look like such that you need a mask ?
> >
> > According to the datasheet the RDID command (0x9f) returns the following
> > bytes:
> >
> > byte 0: Manufacturer ID = 0x01
> > byte 1,2: Device ID = 0x02, 0x15 (same as S25FL032A)
> > byte 3: Extended ID = 0x4d
> > byte 4,5,6: Spansion reserved (do not use).
> >
> > byte 4 is read as 0x00 on my part, but due to the above explaination, I
> > cannot say for sure it is always the same, so I had to implement a mask
> > to check for it.
>
> i'd rather we delay adding code to support something that may never change.
> so drop the whole idmask2 stuff and wait for it to become an actual problem
> -mike
I agree that chances this ever breaks might seem rather tiny, but if it ever
does break, waiting for it to happen could trigger a much bigger problem than
it is to add these few lines; in the worst case, in some distant future, some
boards will just not work for no apparent reason (if spansion decided to do
something with byte 4 without notifying), and nobody will remember this
discussion anymore...
OTOH, you decide. It's ok with me if you want to leave it out. Given the fact
that you had already accepted this patch, should I send a new version (without
the mask)?
Best regards,
--
David Jander
Protonic Holland.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Start/stop of network devices (was: Re: [PATCH] UEC PHY: Speed up initial PHY neg.)
> > Hi Ben, > > [Jocke deleted from CC as this is not about the patch anymore] But I still want to know what will happen to it. I didn't send this patch to start another discussion :) Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] AT91: fix at91sam9260.h for AT91SAM9XE
For some reason Atmel changed the GPBR address for the AT91SAM9XE to be different from the engineering samples and the AT91SAM9260. Also let the correct SoC name be defined. Signed-off-by: Reinhard Meyer --- one probably need not understand why the first mail got clobbered up in spaces at start of each line... arch/arm/include/asm/arch-at91/at91sam9260.h | 19 +++ 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/arch/arm/include/asm/arch-at91/at91sam9260.h b/arch/arm/include/asm/arch-at91/at91sam9260.h index ec04318..91ea800 100644 --- a/arch/arm/include/asm/arch-at91/at91sam9260.h +++ b/arch/arm/include/asm/arch-at91/at91sam9260.h @@ -59,7 +59,16 @@ #define AT91_RTT_BASE 0xfd20 #define AT91_PIT_BASE 0xfd30 #define AT91_WDT_BASE 0xfd40 -#define AT91_GPR_BASE 0xfd50 +/* + * The latest revision of the AT91SAM9XE has the GPBR moved up 0x10. + * (its not a bug, its a feature...) + * Maybe we can figure a dynamic way to handle this later... + */ +#ifdef CONFIG_AT91SAM9XE +# define AT91_GPR_BASE 0xfd60 +#else +# define AT91_GPR_BASE 0xfd50 +#endif #ifdef CONFIG_AT91_LEGACY @@ -140,10 +149,12 @@ /* * Cpu Name */ -#if defined(CONFIG_AT91SAM9260) -#define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9260" +#if defined(CONFIG_AT91SAM9XE) +# define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9XE" +#elif defined(CONFIG_AT91SAM9260) +# define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9260" #elif defined(CONFIG_AT91SAM9G20) -#define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9G20" +# define CONFIG_SYS_AT91_CPU_NAME "AT91SAM9G20" #endif #endif -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] TEST - please ignore
<- 0 spaces <- 1 space <- 2 spaces <- 3 spaces <- 4 spaces ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: Add support for S25FL032P spi nor-flash
On Tuesday, August 24, 2010 14:36:43 David Jander wrote:
> On Tuesday 24 August 2010 06:06:26 pm Mike Frysinger wrote:
> > On Tuesday, August 24, 2010 02:39:16 David Jander wrote:
> > > On Monday 23 August 2010 06:31:26 pm Mike Frysinger wrote:
> > > > On Monday, August 23, 2010 09:12:16 David Jander wrote:
> > > > > + {
> > > > > + .idcode1 = SPSN_ID_S25FL032A,
> > > > > + .idcode2 = SPSN_EXT_ID_S25FL032P,
> > > > > + .idmask2 = 0xff00,
> > > >
> > > > what does the idcode2 look like such that you need a mask ?
> > >
> > > According to the datasheet the RDID command (0x9f) returns the
> > > following bytes:
> > >
> > > byte 0: Manufacturer ID = 0x01
> > > byte 1,2: Device ID = 0x02, 0x15 (same as S25FL032A)
> > > byte 3: Extended ID = 0x4d
> > > byte 4,5,6: Spansion reserved (do not use).
> > >
> > > byte 4 is read as 0x00 on my part, but due to the above explaination, I
> > > cannot say for sure it is always the same, so I had to implement a mask
> > > to check for it.
> >
> > i'd rather we delay adding code to support something that may never
> > change. so drop the whole idmask2 stuff and wait for it to become an
> > actual problem
>
> I agree that chances this ever breaks might seem rather tiny, but if it
> ever does break, waiting for it to happen could trigger a much bigger
> problem than it is to add these few lines; in the worst case, in some
> distant future, some boards will just not work for no apparent reason (if
> spansion decided to do something with byte 4 without notifying), and
> nobody will remember this discussion anymore...
considering the problem is rather minute and easily detected, i dont think
it'll be that big of a deal
> OTOH, you decide. It's ok with me if you want to leave it out. Given the
> fact that you had already accepted this patch, should I send a new version
> (without the mask)?
it's in a branch of mine that i can throw away, so just send a new patch based
on current mainline and i'll integrate it. thanks !
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Creating a new Bootloader
Hello, I am developing a new board based on the OMAP3530 processor. It is not the Beagleboard, but similar. Where do I start to begin making a U-boot bootloader for my custom board? Thanks. Patrick ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] SPI: cmd_spi.c: add option to specify bus and mode
On Tuesday, August 24, 2010 04:05:19 Reinhard Meyer wrote: > Dear Mike Frysinger, > > were you going to send an updated version ? > > Soon. Currently I have other issues and a rather > "dirty" working tree :) dont sweat it. just wanted to make sure it wasnt lost/forgotten/ignored. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Creating a new Bootloader
Le 24/08/2010 22:29, Boswell, Patrick a écrit : > Hello, > > I am developing a new board based on the OMAP3530 processor. It is not > the Beagleboard, but similar. > > Where do I start to begin making a U-boot bootloader for my custom > board? > > Thanks. > > Patrick I would suggest pulling the latest git u-boot source code and create a new board directory under board/, basing it on board/ti/beagle. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for the MPC5121e USB Host controller.
Hi Elinar, > The root hub is detected and also it detects a device connected to the > controller. > However, by testing with a usbstick (mass storage) it fails to detect the > device as a storage device. > > I have here a debug printout which is being printed (with debug enabled) > during execution of the command 'usb start': > > Unfortunately, our experience also shows some USB Mass Storage Devices work better than others. For example, we are able to reproduce some of the issues we have on the SheevaPlug (Marvel Kirkwood ARM) with the same combinations of hubs and USB sticks. Do you have another USB Host board available to try to see if your issue is reproducible across platforms? Are you able to list the hub and the USB Stick that you are using below? Is it reproducible across different hubs and sticks? For example, SMSC hubs tend to exhibit the problems far more than Genesys Logic hubs. I have no experience with Cypress hubs as to whether they perform any better or not. If you search the mailing list, I asked about the same issue some time ago. -- Damien ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] AT91: add RTT and GPBR based RTC
Hi Reinhard, > -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Reinhard Meyer > Sent: Friday, August 20, 2010 10:00 PM > To: u-boot > Subject: [U-Boot] [PATCH v2] AT91: add RTT and GPBR based RTC > > adds kernel compatible RTC handling to u-boot using the RTT > and one GPBRegister > > Signed-off-by: Reinhard Meyer > --- > This patch replaces the wrongly split and outdated patch from > 05.07.2010 > arch/arm/include/asm/arch-at91/at91_gpbr.h | 45 + > arch/arm/include/asm/arch-at91/at91_rtt.h | 36 ++ > drivers/rtc/Makefile |1 + > drivers/rtc/at91sam9.c | 100 Some of Atmel's ARM926EJS chips have builtin RTC, for example, SAM9G45 SAM9M10 SAM9RL and new X5 serials. May we take this into account at this stage? We can use big #ifdef to add real RTC support in drivers/rtc/at91sam9.c - or - We can rename drivers/rtc/at91sam9.c to , for example, drivers/rtc/at91sam9_rtt.c, and let drivers/rtc/at91sam9.c for the real RTC support. What's your opinion? Thanks. BR, Eric [...] > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] AT91: add RTT and GPBR based RTC
Dear Xu, Hong, >> adds kernel compatible RTC handling to u-boot using the RTT >> and one GPBRegister >> ... >> arch/arm/include/asm/arch-at91/at91_gpbr.h | 45 + >> arch/arm/include/asm/arch-at91/at91_rtt.h | 36 ++ >> drivers/rtc/Makefile |1 + >> drivers/rtc/at91sam9.c | 100 > > Some of Atmel's ARM926EJS chips have builtin RTC, for example, SAM9G45 > SAM9M10 SAM9RL and new X5 serials. > May we take this into account at this stage? > > We can use big #ifdef to add real RTC support in drivers/rtc/at91sam9.c I don't think that makes sense, assuming the "real rtc" uses registers that count like HHMMSS DDMMYY. It would be completely different code. > - or - > > We can rename drivers/rtc/at91sam9.c to , for example, > drivers/rtc/at91sam9_rtt.c, and let drivers/rtc/at91sam9.c for the real RTC > support. I'd go with that, and even suggest naming the maybe upcoming "real rtc" driver at91sam9_rtc.c to give a clearer indication of the different approaches. Besides, for LinuX the rtt makes more sense since it directly counts in seconds since epoch. Thanks Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] AT91: add RTT and GPBR based RTC
Dear Xu, Hong, > Some of Atmel's ARM926EJS chips have builtin RTC, for example, SAM9G45 > SAM9M10 SAM9RL and new X5 serials. > May we take this into account at this stage? Maybe you can help me here: the 9260 and the 9XE-ENG Sample (soldered on my EK) have the GPBRs at 0xfd50. Its sold as a feature (but I think its a bug) that the current Mask of the 9XE has the GPBRs at 0xfd60 (0xfd50 designated "reserved" now). Is there a simple way to distinguish between both masks? Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] DNS323 (Orion5x) must double ORION5X_SZ_BOOTROM to access full flash
> -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Tuesday, August 24, 2010 6:22 PM > To: Rogan Dawes > Cc: Chris Moore; u-boot@lists.denx.de; Prafulla Wadaskar > Subject: Re: [U-Boot] DNS323 (Orion5x) must double > ORION5X_SZ_BOOTROM to access full flash > > Le 24/08/2010 14:17, Rogan Dawes a écrit : > > On 2010/08/24 1:34 PM, Albert ARIBAUD wrote: > >> Le 24/08/2010 09:47, Rogan Dawes a écrit : > >> > >>> Yes, I still have the vendor u-boot flashed, so I can > still see its > >>> configuration. And, yes, it does allow reading the full > 8MB of flash. > >> > >>> Vendor u-boot: > >> > >>> f1020040: 007f0f11 ff80 > >> > >>> Mainline (8MB window): > >> > >>> f1020070: 003f0f11 ff80 ..?. > >> > >>> Mainline (16MB window): > >> > >>> f1020070: 007f0f11 ff80 > >> > >> The good news is that your flash works normally. > >> > >> The bad news is that the mainline settings you are showing here are > >> wrong with respect to the ORION5X_SZ_BOOTROM: A 16 MB > window would be > >> 00ff0f11. 007f0f11 is 8MB, and 003f0f11 is 4 MB. Thus, > what you think is > >> a 16MB widow is actually a 8MB one, and the 8MB one is > actually 4MB, > >> which explains the issues you have. > >> > >> I've just checked the code for computing the window size > in mainline > >> u-boot, and it is off by one, reducing the actual window mapping by > >> half. :( > >> > >> They weird thing is that it affect *all* windows, RAM included; we > >> should have seen other issues! I'll do some checks later today and > >> provide an officiel bugfix this evening. > >> > >> Amicalement, > > > > Hi Albert, > > > > Thanks for looking at this. > > > > Do you mean that your own u-boot is also misconfigured? > > > > Rogan > > Yes, it is, to the point that just like you, I can only flash > the lower > half of my (512KB) flash -- when I did the flash tests, it escaped me > because I only erased and flashed small sectors at the > beginning of the > flash. :/ > > As for RAM, thanks to Wolfgang's suggestion to use > get_ram_size() rather > than the (now evidently buggy) SoC's calculation routine, mainline > u-boot actually finds the real amount of RAM regardless of any macro > value, which explains why u-boot could access RAM above the > first half, > and especially the upmost megabyte as I am doing now. > > Bugfix patch on its way, and adding Prafulla as this bug also hits > kirkwood SoC code from which the calculation code was taken. Thanks I will check this for Kirkwood Regards.. Prafulla . . > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMV7: S5P: rename the member of gpio structure
Typically we declare the name of gpio structure to "gpio",
so it was duplicated around the name. (e.g: gpio->gpio_a)
This patch modified the naming that is removing "gpio_".
Signed-off-by: Minkyu Kang
Signed-off-by: Kyungmin Park
---
arch/arm/include/asm/arch-s5pc1xx/gpio.h | 172 +++---
board/samsung/goni/goni.c|8 +-
board/samsung/smdkc100/smdkc100.c|2 +-
3 files changed, 91 insertions(+), 91 deletions(-)
diff --git a/arch/arm/include/asm/arch-s5pc1xx/gpio.h
b/arch/arm/include/asm/arch-s5pc1xx/gpio.h
index 9a7faed..2df33a6 100644
--- a/arch/arm/include/asm/arch-s5pc1xx/gpio.h
+++ b/arch/arm/include/asm/arch-s5pc1xx/gpio.h
@@ -33,96 +33,96 @@ struct s5p_gpio_bank {
};
struct s5pc100_gpio {
- struct s5p_gpio_bank gpio_a0;
- struct s5p_gpio_bank gpio_a1;
- struct s5p_gpio_bank gpio_b;
- struct s5p_gpio_bank gpio_c;
- struct s5p_gpio_bank gpio_d;
- struct s5p_gpio_bank gpio_e0;
- struct s5p_gpio_bank gpio_e1;
- struct s5p_gpio_bank gpio_f0;
- struct s5p_gpio_bank gpio_f1;
- struct s5p_gpio_bank gpio_f2;
- struct s5p_gpio_bank gpio_f3;
- struct s5p_gpio_bank gpio_g0;
- struct s5p_gpio_bank gpio_g1;
- struct s5p_gpio_bank gpio_g2;
- struct s5p_gpio_bank gpio_g3;
- struct s5p_gpio_bank gpio_i;
- struct s5p_gpio_bank gpio_j0;
- struct s5p_gpio_bank gpio_j1;
- struct s5p_gpio_bank gpio_j2;
- struct s5p_gpio_bank gpio_j3;
- struct s5p_gpio_bank gpio_j4;
- struct s5p_gpio_bank gpio_k0;
- struct s5p_gpio_bank gpio_k1;
- struct s5p_gpio_bank gpio_k2;
- struct s5p_gpio_bank gpio_k3;
- struct s5p_gpio_bank gpio_l0;
- struct s5p_gpio_bank gpio_l1;
- struct s5p_gpio_bank gpio_l2;
- struct s5p_gpio_bank gpio_l3;
- struct s5p_gpio_bank gpio_l4;
- struct s5p_gpio_bank gpio_h0;
- struct s5p_gpio_bank gpio_h1;
- struct s5p_gpio_bank gpio_h2;
- struct s5p_gpio_bank gpio_h3;
+ struct s5p_gpio_bank a0;
+ struct s5p_gpio_bank a1;
+ struct s5p_gpio_bank b;
+ struct s5p_gpio_bank c;
+ struct s5p_gpio_bank d;
+ struct s5p_gpio_bank e0;
+ struct s5p_gpio_bank e1;
+ struct s5p_gpio_bank f0;
+ struct s5p_gpio_bank f1;
+ struct s5p_gpio_bank f2;
+ struct s5p_gpio_bank f3;
+ struct s5p_gpio_bank g0;
+ struct s5p_gpio_bank g1;
+ struct s5p_gpio_bank g2;
+ struct s5p_gpio_bank g3;
+ struct s5p_gpio_bank i;
+ struct s5p_gpio_bank j0;
+ struct s5p_gpio_bank j1;
+ struct s5p_gpio_bank j2;
+ struct s5p_gpio_bank j3;
+ struct s5p_gpio_bank j4;
+ struct s5p_gpio_bank k0;
+ struct s5p_gpio_bank k1;
+ struct s5p_gpio_bank k2;
+ struct s5p_gpio_bank k3;
+ struct s5p_gpio_bank l0;
+ struct s5p_gpio_bank l1;
+ struct s5p_gpio_bank l2;
+ struct s5p_gpio_bank l3;
+ struct s5p_gpio_bank l4;
+ struct s5p_gpio_bank h0;
+ struct s5p_gpio_bank h1;
+ struct s5p_gpio_bank h2;
+ struct s5p_gpio_bank h3;
};
struct s5pc110_gpio {
- struct s5p_gpio_bank gpio_a0;
- struct s5p_gpio_bank gpio_a1;
- struct s5p_gpio_bank gpio_b;
- struct s5p_gpio_bank gpio_c0;
- struct s5p_gpio_bank gpio_c1;
- struct s5p_gpio_bank gpio_d0;
- struct s5p_gpio_bank gpio_d1;
- struct s5p_gpio_bank gpio_e0;
- struct s5p_gpio_bank gpio_e1;
- struct s5p_gpio_bank gpio_f0;
- struct s5p_gpio_bank gpio_f1;
- struct s5p_gpio_bank gpio_f2;
- struct s5p_gpio_bank gpio_f3;
- struct s5p_gpio_bank gpio_g0;
- struct s5p_gpio_bank gpio_g1;
- struct s5p_gpio_bank gpio_g2;
- struct s5p_gpio_bank gpio_g3;
- struct s5p_gpio_bank gpio_i;
- struct s5p_gpio_bank gpio_j0;
- struct s5p_gpio_bank gpio_j1;
- struct s5p_gpio_bank gpio_j2;
- struct s5p_gpio_bank gpio_j3;
- struct s5p_gpio_bank gpio_j4;
- struct s5p_gpio_bank gpio_mp0_1;
- struct s5p_gpio_bank gpio_mp0_2;
- struct s5p_gpio_bank gpio_mp0_3;
- struct s5p_gpio_bank gpio_mp0_4;
- struct s5p_gpio_bank gpio_mp0_5;
- struct s5p_gpio_bank gpio_mp0_6;
- struct s5p_gpio_bank gpio_mp0_7;
- struct s5p_gpio_bank gpio_mp1_0;
- struct s5p_gpio_bank gpio_mp1_1;
- struct s5p_gpio_bank gpio_mp1_2;
- struct s5p_gpio_bank gpio_mp1_3;
- struct s5p_gpio_bank gpio_mp1_4;
- struct s5p_gpio_bank gpio_mp1_5;
- struct s5p_gpio_bank gpio_mp1_6;
- struct s5p_gpio_bank gpio_mp1_7;
- struct s5p_gpio_bank gpio_mp1_8;
- struct s5p_gpio_bank gpio_mp2_0;
- struct s5p_gpio_bank gpio_mp2_1;
- struct s5p_gpio_bank gpio_mp2_2;
- struct s5p_gpio_bank gpio_mp2_3;
- struct s5p_gpio_bank gpio_mp2_4;
- struct s5p_gpio_bank gpio_mp2_5;
- struct s5p_gpi
Re: [U-Boot] [PATCH v2] AT91: add RTT and GPBR based RTC
Hi Reinhard, > -Original Message- > From: Reinhard Meyer [mailto:u-b...@emk-elektronik.de] > Sent: Wednesday, August 25, 2010 10:23 AM > To: Xu, Hong > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH v2] AT91: add RTT and GPBR based RTC > > Dear Xu, Hong, > > Some of Atmel's ARM926EJS chips have builtin RTC, for > example, SAM9G45 SAM9M10 SAM9RL and new X5 serials. > > May we take this into account at this stage? > Maybe you can help me here: > the 9260 and the 9XE-ENG Sample (soldered on my EK) have the > GPBRs at 0xfd50. > Its sold as a feature (but I think its a bug) that the > current Mask of the 9XE has the GPBRs at 0xfd60 > (0xfd50 designated "reserved" now). > Is there a simple way to distinguish between both masks? Per the latest datasheet from Atmel's official website, 0xFD60 is GPBR base address for SAM9XE 0xFD50 is GPBR base address for SAM9260. We'd use this for official EK board and forget Eng samples. If you want to distinguish different chip revision, DBGU_CIDR and DBGU_EXID may help. BR, Eric > Reinhard > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] Release delayed
Hello, I'm sorry, but there will be an unplanned (additional) delay to the current release. My plan was to get some work done while I'm on vacation, but it turns out that "mobile broadband" here means a GSM link with a max of 3.5 kB/s downstream, and the local WiFi hotspot gives less than 60 kB/s, and that only occasionally. Under such conditions I decided to really take a break instead. I think I'll resume regular work for U-Boot around Sep 05. Sorry for the delay... 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 only perfect science is hind-sight. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] AT91: add RTT and GPBR based RTC
Dear Xu, Hong, > Per the latest datasheet from Atmel's official website, 0xFD60 is GPBR > base address for SAM9XE > 0xFD50 is GPBR base address for SAM9260. True. I still think it was not planned like that. It just makes live more complicated since otherwise, as long as one does not use the internal flash, the code for 9260 and 9XE would be identical... > > We'd use this for official EK board and forget Eng samples. Fine with me. I tried to send a patch for at91sam9260.h this night but it was mangled. I'll try to repost that later. My way to define for the 9XE is currently as follows: #define CONFIG_AT91SAM9260 #define CONFIG_AT91SAM9XE That avoids extra #if added to several files which would be necessary if only CONFIG_AT91SAM9XE were defined. > If you want to distinguish different chip revision, DBGU_CIDR and DBGU_EXID > may help. Provided they are different between ENG and actual masks... I don't have the XE-EK with the ENG sample ready right now to check that. Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
