Re: [U-Boot] [U-Boot, v2] powerpc/mpc85xx:Disable Debug TLB entry before init_tlbs
On 06/24/2013 08:44 AM, Prabhakar Kushwaha wrote: On 06/22/2013 02:42 AM, Scott Wood wrote: On 06/21/2013 04:05:37 PM, Fleming Andy-AFLEMING wrote: On Jun 21, 2013, at 3:59 PM, Scott Wood wrote: > On 06/21/2013 03:38:48 PM, Andy Fleming wrote: >> On Thu, Jun 13, 2013 at 10:14:00AM +0530, Prabhakar Kushwaha wrote: >> > init_tlbs() initialize all the TLB entries required for the system. >> > >> > So disable DEBUG TLB entry before TLB entries initialization. >> > >> > Signed-off-by: Prabhakar Kushwaha >> Applied, with fixes. >> > diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c >> > index f4403c2..340b063 100644 >> > --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c >> > +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c >> > @@ -180,5 +180,9 @@ void cpu_init_early_f(void) >> > >> > invalidate_tlb(1); >> > >> > +#if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) && !defined(CONFIG_SPL_BUILD) >> > +disable_tlb(CONFIG_SYS_PPC_E500_DEBUG_TLB); >> > +#endif >> Had to add CONFIG_NAND_SPL here, as well, just for future reference > > Why exclude all SPLs? Only minimal SPLs skip creating the debug TLB. The definition of disable_tlb() is excluded when NAND_SPL is defined. I'm talking about new-SPL, not NAND_SPL. My comment is about the original patch (I made the comment before internally), not your edit to it. as per comment from Scott, we should have below define. It takes care of SPL minimal + nand_spl #if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) && !defined(CONFIG_SPL_INIT_MINIMAL) && !defined(CONFIG_NAND_SPL) May I resend this patch? just a afterthought, current modified* patch is correct i.e. " #if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) && !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_NAND_SPL)" DEBUG TLB never been created for SPL & NAND_SPL so no need to disable. Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] EXYNOS: Add API for power reset and shutdown
Dear Rajeshwari Shinde,
On 04/04/13 16:06, Rajeshwari Shinde wrote:
> This patch adds API's to reset and shutdown the power of
> EXYNOS boards
> power_shutdown: powers off the board by deasserting PS_HOLD pin.
> power_reset: this function software resets the Exynos board when called.
>
> Signed-off-by: Che-Liang Chiou
> Signed-off-by: Rajeshwari Shinde
> ---
> arch/arm/cpu/armv7/exynos/power.c| 31
> ++
> arch/arm/include/asm/arch-exynos/power.h | 10 +
> 2 files changed, 41 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/exynos/power.c
> b/arch/arm/cpu/armv7/exynos/power.c
> index 6375a81..2b65bbe 100644
> --- a/arch/arm/cpu/armv7/exynos/power.c
> +++ b/arch/arm/cpu/armv7/exynos/power.c
> @@ -113,6 +113,25 @@ void set_ps_hold_ctrl(void)
> }
>
I know that is not related your patch.
But, please remove blank line.
>
> +void exynos5_power_shutdown(void)
> +{
> + struct exynos5_power *power =
> + (struct exynos5_power *)samsung_get_base_power();
> +
> + clrbits_le32(&power->ps_hold_control, EXYNOS_PS_HOLD_CONTROL_DATA_HIGH);
> +}
This function is same purpose with set_ps_hold_ctrl.
So please, add it to set_ps_hold_ctrl.
> +
> +void exynos5_power_reset(void)
> +{
> + struct exynos5_power *power =
> + (struct exynos5_power *)samsung_get_base_power();
> +
> + /* Clear inform1 so there's no change we think we've got a wake reset */
> + power->inform1 = 0;
> +
> + setbits_le32(&power->swreset, 1);
> +}
> +
> static void exynos5_set_xclkout(void)
> {
> struct exynos5_power *power =
> @@ -140,3 +159,15 @@ void set_hw_thermal_trip(void)
> setbits_le32(&power->ps_hold_control, POWER_ENABLE_HW_TRIP);
> }
> }
> +
> +void power_shutdown(void)
> +{
> + if (cpu_is_exynos5())
> + exynos5_power_shutdown();
> +}
> +
> +void power_reset(void)
swreset?
> +{
> + if (cpu_is_exynos5())
> + exynos5_power_reset();
> +}
please move this function under the exynos5_power_reset.
or move exynos5_power_reset to here.
> diff --git a/arch/arm/include/asm/arch-exynos/power.h
> b/arch/arm/include/asm/arch-exynos/power.h
> index 3549667..6844e0f 100644
> --- a/arch/arm/include/asm/arch-exynos/power.h
> +++ b/arch/arm/include/asm/arch-exynos/power.h
> @@ -888,4 +888,14 @@ void set_ps_hold_ctrl(void);
> * source as XXTI
> */
> void set_xclkout(void);
> +
> +/*
> + * Power off the system; it should never return.
> + */
> +void power_shutdown(void);
> +
> +/*
> + * Perform a software reset.
> + */
please check comment rule.
One line comment should be.. /* */
> +void power_reset(void);
> #endif
>
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] exynos: Adjust the starting MIF voltage to 1.05v
On 12/05/13 03:50, Simon Glass wrote: > On Mon, Apr 15, 2013 at 11:34 AM, Bernie Thompson > wrote: >> Some Exynos5250 silicon may require 1.05v on the MIF to be stable, so to be >> safe we can default to 1.05v instead of 1.00v. This can be set optimally >> later >> in the boot process by the kernel. >> >> The 0x6 value for 1.05v comes from the MAX77686 datasheet. >> >> Signed-off-by: Bernie Thompson > > Acked-by: Simon Glass > >> --- >> board/samsung/smdk5250/smdk5250.c | 2 +- >> include/power/max77686_pmic.h | 2 ++ >> 2 files changed, 3 insertions(+), 1 deletion(-) >> applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V1 1/1] EXYNOS5: I2C: Add FDT and non-FDT support for I2C
On 12/05/13 03:53, Simon Glass wrote: > On Thu, Apr 4, 2013 at 12:27 AM, Amar wrote: >> This patch updates the function board_i2c_init() to add support for both >> FDT and non-FDT for I2C, and initialise the I2C channels. >> >> Signed-off-by: Amar > > Acked-by: Simon Glass > applied to u-boot-samsung Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, am33xx: move s_init to a common place
Hi Heiko, On Thursday 20 June 2013 09:22 AM, Heiko Schocher wrote: Hello Tom, Am 14.06.2013 16:58, schrieb Tom Rini: On Fri, Jun 14, 2013 at 07:59:26AM +0200, Heiko Schocher wrote: Hello Tom, Am 13.06.2013 17:53, schrieb Tom Rini: On Thu, Jun 13, 2013 at 05:53:17AM +0200, Heiko Schocher wrote: move s_init from every board code to a common place. Signed-off-by: Heiko Schocher Cc: Tom Rini Cc: Matt Porter Cc: Lars Poeschel Cc: Tom Rini Cc: Enric Balletbo i Serra --- This patch is based on the following patches: - [U-Boot,v2] arm, am33xx: move rtc32k_enable() to common place http://patchwork.ozlabs.org/patch/248908/ - [U-Boot] arm, am33xx: move uart soft reset code to common place http://patchwork.ozlabs.org/patch/248508/ These two apply best to u-boot-ti, and with them this patch doesn't apply cleanly. Please sort that out. I based my patches on u-boot ... I look at this .. The following adds moving ti814x_evm into the mix and I've sent Matt some binaries to give a whirl to test on the board: [...] /* * Basic board specific setup. Pinmux has been handled already. Please fold into v2 Signed-off-by: Tom Rini Ok, thanks! There's a minor bug in what I posted, however. ti814x needs timer_init called _before_ pll_init() as setting the sata clocks (which are shared with other periphrals that we do enable right now) needs udelay(50) to settle as we go along. That also needs to be commented in the code as I had to think about it for a bit to recall exactly what was going on. Do you have an update here for me? We can have a timer_init for am33xx boards also. It doesn't harm. So keep timer_init in your common s_init BTW: I just realized that I have on one of the three boards a problem, that in spl code calling the rtc32k_enable() crashes ... which votes against moving this to a common place ... I haveno real idea why ... did you heard from such a behaviour? Is there some am335x soc, which differs from the others? On which board it is giving a problem? Did you make sure clocks for rtc are enabled? I am making a cleanup series for am33xx boards. If you don't mind can I take this patch as part of my series. Thanks and regards, Lokesh You aren't using a different clock crystal rate than the reference platforms, are you? I know that's a problem that needs solving still. I am prospecting, whats going on here ... but have no real idea, why it is not possible to write this registers ... if writing this registers, cpu hang ... But I want to have a common function here ... maybe it is OK to make the rtc32k_enable() call configurable through a define? Saying "CONFIG_SPL_AM33XX_DO_NOT_ENABLE_RTC32K" and document in the u-boot README this define, and why it is necessary? bye, Heiko ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] powerpc/mpc85xx:Disable Debug TLB entry before init_tlbs
On 06/22/2013 02:42 AM, Scott Wood wrote: On 06/21/2013 04:05:37 PM, Fleming Andy-AFLEMING wrote: On Jun 21, 2013, at 3:59 PM, Scott Wood wrote: > On 06/21/2013 03:38:48 PM, Andy Fleming wrote: >> On Thu, Jun 13, 2013 at 10:14:00AM +0530, Prabhakar Kushwaha wrote: >> > init_tlbs() initialize all the TLB entries required for the system. >> > >> > So disable DEBUG TLB entry before TLB entries initialization. >> > >> > Signed-off-by: Prabhakar Kushwaha >> Applied, with fixes. >> > diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c >> > index f4403c2..340b063 100644 >> > --- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c >> > +++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c >> > @@ -180,5 +180,9 @@ void cpu_init_early_f(void) >> > >> > invalidate_tlb(1); >> > >> > +#if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) && !defined(CONFIG_SPL_BUILD) >> > +disable_tlb(CONFIG_SYS_PPC_E500_DEBUG_TLB); >> > +#endif >> Had to add CONFIG_NAND_SPL here, as well, just for future reference > > Why exclude all SPLs? Only minimal SPLs skip creating the debug TLB. The definition of disable_tlb() is excluded when NAND_SPL is defined. I'm talking about new-SPL, not NAND_SPL. My comment is about the original patch (I made the comment before internally), not your edit to it. as per comment from Scott, we should have below define. It takes care of SPL minimal + nand_spl #if defined(CONFIG_SYS_PPC_E500_DEBUG_TLB) && !defined(CONFIG_SPL_INIT_MINIMAL) && !defined(CONFIG_NAND_SPL) May I resend this patch? Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 02/14] net: ftgmac100: add MMU/D-cache support
2013/6/23 Albert ARIBAUD : > Hi Kuo-Jung, > > On Mon, 17 Jun 2013 20:06:52 +0800, Kuo-Jung Su > wrote: > >> 3. No matter if MMU/D-cache is on or off, this patch >>always depends on previous patch: >> >>arm: dma_alloc_coherent: malloc() -> memalign(). >> >>Because the FTGMAC100 expects the tx/rx descriptors >>are always be aligned to 16-bytes boundary. > > Nitpick: as a general rule, the commit message does not need to mention > that a patch in a series depends on a previous one; this is implied by > the series itself. > > In fact, it should even /refrain/ from doing so because even though the > series is usually applied atomically, it is not impossible that a an > unrelated 'hot' bugfix patch slip in the middle of it, so "previous > patch", which makes sense at submission time, might not make sense any > more later. > > Personally I like the commit message to only provide a short explanation > of the whys and hows of the patch itself, and put any additional info > after the commit message separator "---" below or, if using patman, in > the cover letter. > Got it, thanks -- Best wishes, Kuo-Jung Su ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 12/14] arm: add Faraday specific boot command
2013/6/23 Albert ARIBAUD : > Hi Kuo-Jung, > > On Mon, 17 Jun 2013 20:07:02 +0800, Kuo-Jung Su > wrote: > >> From: Kuo-Jung Su >> >> At the time of writting, none of Faraday NAND & SPI controllers >> supports XIP (eXecute In Place). So the Faraday A360/A369 SoC has >> to implement a 1st level bootstrap code stored in the embedded ROM >> inside the SoC. >> >> After power-on, the ROM code (1st level bootstrap code) would load >> the 2nd bootstrap code into SRAM without any SDRAM initialization. >> >> The 2nd bootstrap code would then initialize SDRAM and load the >> generic firmware (u-boot/linux) into SDRAM, and finally make >> a long-jump to the firmware. >> >> Which means the SPL design of U-boot would never fit to A360/A369, >> since it's usually not possible to alter a embedded ROM code. >> And because both the 1st & 2nd level bootstrap code use the private >> Faraday Firmware Image Format, it would be better to drop U-boot >> image support to simplify the design. > > Please reword the last sentence: you're not suggesting "to drop > U-boot support" from U-Boot, right? You're only suggesting adding the > Faraday image format. > 1. Got it, I'll reword the last sentence. 2. Yes, what I meant is "Drop u-boot image support in Faraday image utility" However I forget that's a tool which is not actually related to U-boot. :P > Also, maybe the long explanation should go in the cover letter and a > single shorter paragraph should be given as commit message here. > Got it, thanks. -- Best wishes, Kuo-Jung Su ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc/CoreNet: Allow pbl images to take u-boot images != 512K
Hi Andy,
>>>On 6/22/2013 at 08:31 AM, Andy Fleming wrote:
> On Mon, May 27, 2013 at 10:51:46AM +1200, Chris Packham wrote:
>> From: Chris Packham
>>
>> Instead of assuming that SYS_TEXT_BASE is 0xFFF8 calculate the initial
>> pbl command offset by subtracting the image size from the top of the
>> 24-bit address range. Also increase the size of the memory buffer to
>> accommodate a larger output image.
>>
>> Signed-off-by: Chris Packham
>
> I've applied this (thanks), but I'll note it had a warning about unused
> variable "size". Because it was unused. Please build-test any patches,
> and ensure they are free of warnings.
>> + * The PBL can load up to 64 bytes at a time, so we split the U-Boot
>> + * image into 64 byte chunks. PBL needs a command for each piece, of
>> + * the form "81xx", where "xx" is the offset. Calculate the
>> + * start offset by subtracting the size of the u-boot image from the
>> + * top of the allowable 24-bit range.
>> + */
>> +static void init_next_pbl_cmd(FILE *fp_uboot)
>> +{
>> +struct stat st;
>> +int fd = fileno(fp_uboot);
>> +size_t size;
>
> This was the variable, for future reference.
OK I'll keep an eye out in the future. I usually run with CFLAGS+='-Wall
-Werror'
so I'm not sure how I missed this.
>> +
>> +if (fstat(fd, &st) == -1) {
>> +printf("Error: Could not determine u-boot image size. %s\n",
>> +strerror(errno));
>> +exit(EXIT_FAILURE);
>> +}
>> +
>> +next_pbl_cmd = 0x8200 - st.st_size;
>> +}
>
> Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Help with Glomation GESBC-9G20
I am trying to upgrade U-Boot on a Glomation GESBC-9G20 (a derivative of the Atmel AT91SAM9G20-EK) to a version that supports UBIFS. The latest U-Boot does not work. (See also my report on the Glomation user forum, http://glomation.net/smf/index.php/topic,1389.0.html.) The GESBC-9G20 comes with a patched U-Boot 1.3.4. I built U-Boot 1.3.4 with Glomation patches using both the Glomation ARM cross development tool chain and the Code Sourcery 2013.05 ARM EABI cross development tool chain. Both work fine. I built the latest U-Boot release (2013.04) and the U-Boot git tree (2013.07 preview) version using the Code Sourcery tool chain (the Glomation tool chain is too old). Neither work. They both hang at: ˇRomBOOT Start AT91Bootstrap... In topic http://glomation.net/smf/index.php/topic,1382.0.html, it says the latest U-Boot supports the AT91SAM9G20. That seems to be true for an Atmel AT91SAM9G20-EK. But, U-Boot built for an AT91SAM9G20-EK does not seem to work on my GESBC-9G20. Glomation's response about the differences: The GESBC-9G20 is a slimmed down version of the Atmel AT91SAM9G20-ek (the earlier version with 1 SD card slot). The audio, serial EEPROM, etc were omitted. The binary code (bootstrap, U-Boot, kernel) from Atmel can run directly on the GESBC-9G20. As far as I can tell from the SAM-BA download log file, U-Boot fits in its flash partition: -I- === Erase all the NAND flash blocs and test the erasing === -I- GENERIC::EraseAll -I- === Load the bootstrap: nandflash_at91sam9-ek in the first sector === GENERIC::SendFile nandflash_at91sam9g20ek.bin at address 0x0 -I- File size : 0x1078 byte(s) -I- Complete 0% -I- Writing: 0x1078 bytes at 0x0 (buffer addr : 0x20003E38) -I- 0x1078 bytes written by applet -I- === Load the u-boot in the next sectors === -I- Send File u-boot-2013.07-git.bin at address 0x0002 GENERIC::SendFile u-boot-2013.07-git.bin at address 0x2 -I- File size : 0x3E054 byte(s) -I- Complete 0% -I- Writing: 0x2 bytes at 0x2 (buffer addr : 0x20003E38) -I- 0x2 bytes written by applet -I- Complete 51% -I- Writing: 0x1E054 bytes at 0x4 (buffer addr : 0x20003E38) -I- 0x1E054 bytes written by applet -I- === Load the u-boot environment variables === -I- Send File ubootEnvtFileNandFlash.bin at address 0x0006 GENERIC::SendFile ubootEnvtFileNandFlash.bin at address 0x6 -I- File size : 0x2 byte(s) -I- Complete 0% -I- Writing: 0x2 bytes at 0x6 (buffer addr : 0x20003E38) -I- 0x2 bytes written by applet -I- === Load the Kernel image === -I- Send File uImage-3.2.6 at address 0x0010 GENERIC::SendFile uImage-3.2.6 at address 0x10 -I- === Load the linux file system === -I- Send File 9260rootfs.img at address 0x0040 GENERIC::SendFile 9260rootfs.img at address 0x40 I could use some guidance to track down the problem. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov Below are the steps I followed (plus, I ran SAM-BA under Windows 8 to write the bootstrap, u-boot, kernel, and rootfs to flash memory): • Download and build U-Boot 1.3.4 with Glomation patches using the Glomation ARM cross development tool chain. $ mkdir -p /opt/gesbc-9g20/u-boot $ cd /opt/gesbc-9g20/u-boot $ wget http://ftp.denx.de/pub/u-boot/u-boot-1.3.4.tar.bz2 Download u-boot-1.3.4-exp.5.diff from the Glomation user forum topic, reply #1, at http://glomation.net/smf/index.php/topic,1389.0.html $ tar -xjf u-boot-1.3.4.tar.bz2 $ cd u-boot-1.3.4 $ patch -p1 < ../u-boot-1.3.4-exp.5.diff $ make ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnu- at91sam9g20ek_nandflash_config $ make ARCH=arm CROSS_COMPILE=arm-unknown-linux-gnu- $ cp u-boot.bin /opt/gesbc-9g20/u-boot-1.3.4.bin • Repeat the build using the Code Sourcery ARM cross development tool chain. $ cd /opt/gesbc-9g20/u-boot/u-boot-1.3.4 $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- distclean $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- at91sam9g20ek_nandflash_config $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- $ cp u-boot.bin /opt/gesbc-9g20/u-boot-1.3.4.bin • Download and build the latest U-Boot stable release using the Code Sourcery ARM cross development tool chain. $ cd /opt/u-boot $ wget http://ftp.denx.de/pub/u-boot/u-boot-latest.tar.bz2 $ tar -xjf u-boot-latest.tar.bz2 $ cd u-boot-2013.04 $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- distclean $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- at91sam9g20ek_nandflash_config $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- $ cp u-boot.bin /opt/gesbc-9g20/u-boot-2013.04.bin • Download and build the latest U-Boot development tree using the Code Sourcery ARM cross development tool chain. $ cd /opt/u-boot $ git clone git://git.denx.de/u-boot.git $ cd u-boot $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- distclean $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- at91sam9g20ek_nandflash_config $ make ARCH=arm CROSS_COMPILE=arm-none-eabi- $ cp u-boot.bin /opt/gesbc-9g20/u-boot-2013.07-git.bin ___
Re: [U-Boot] [PULL] u-boot-pxa/master
Dear Mike Dunn, > On 06/23/2013 03:13 AM, Albert ARIBAUD wrote: > > Hi Marek, > > > >>> FYI, I am using the ARM cross-toolchain available in my Ubuntu 13.04. > >> > >> For some reason, I feel the linaro ones were always stuffed with > >> experimental and semi-broken stuff :-( > > > > Maybe they were; all I can say is, the Ubuntu/Linaro toolchain never > > failed me in any way. > > I build my toolchain using the crossdev script, which is a gentoo package. > I've been doing this for years without any problems, except that > occasionally building requires some trial-and-error because of > incompatibilities between gcc/binutils/glibc. But other than that, I am > able to choose the version of each tool. I'll just add my bit into this toolchain onanism ... I build my toolchains with buildcross (it's a debian thing) ... fap fap. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] sf: Warn to use BAR for > 16MiB flashes
On 21-06-2013 19:19, Jagannadha Sutradharudu Teki wrote:
From: Jagannadha Sutradharudu Teki
Warning for > 16MiB flashes to #define CONFIG_SPI_FLASH_BAR
Signed-off-by: Jagannadha Sutradharudu Teki
---
Changes for v3:
-
Changes for v2:
-
drivers/mtd/spi/spi_flash.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 51142d8..a468208 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -557,6 +557,12 @@ struct spi_flash *spi_flash_probe(unsigned int bus,
unsigned int cs,
if (flash->memory_map)
printf(", mapped at %p", flash->memory_map);
puts("\n");
+#ifndef CONFIG_SPI_FLASH_BAR
+ if (flash->size > SPI_FLASH_16MB_BOUN) {
+ puts("SF: Warning - Only lower 16MiB accessible,");
+ puts(" Full access #define CONFIG_SPI_FLASH_BAR\n");
+ }
+#endif
spi_release_bus(spi);
Applied to u-boot-spi/master
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] sf: Add debug messages on spi_flash_read_common
On 21-06-2013 19:19, Jagannadha Sutradharudu Teki wrote:
- Added debug's on spi_flash_read_common()
- Added space
Signed-off-by: Jagannadha Sutradharudu Teki
---
Changes for v3:
-
Changes for v2:
-
drivers/mtd/spi/spi_flash.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index a329850..51142d8 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -254,8 +254,18 @@ int spi_flash_read_common(struct spi_flash *flash, const
u8 *cmd,
struct spi_slave *spi = flash->spi;
int ret;
- spi_claim_bus(spi);
+ ret = spi_claim_bus(flash->spi);
+ if (ret) {
+ debug("SF: unable to claim SPI bus\n");
+ return ret;
+ }
+
ret = spi_flash_cmd_read(spi, cmd, cmd_len, data, data_len);
+ if (ret < 0) {
+ debug("SF: read cmd failed\n");
+ return ret;
+ }
+
spi_release_bus(spi);
return ret;
Applied to u-boot-spi/master
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] sf: Unify spi_flash write code
On 21-06-2013 19:19, Jagannadha Sutradharudu Teki wrote:
Move common flash write code into spi_flash_write_common().
Signed-off-by: Jagannadha Sutradharudu Teki
Acked-by: Simon Glass
---
Changes for v3:
- Used proper comments on spi_flash_write_common
Changes for v2:
-
drivers/mtd/spi/spi_flash.c | 120 ---
drivers/mtd/spi/spi_flash_internal.h | 10 +++
2 files changed, 63 insertions(+), 67 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 6ce82c1..03cecef 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -68,15 +68,15 @@ int spi_flash_cmd_write(struct spi_slave *spi, const u8
*cmd, size_t cmd_len,
return spi_flash_read_write(spi, cmd, cmd_len, data, NULL, data_len);
}
-int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 offset,
- size_t len, const void *buf)
+int spi_flash_write_common(struct spi_flash *flash, const u8 *cmd,
+ size_t cmd_len, const void *buf, size_t buf_len)
{
- unsigned long byte_addr, page_size;
- size_t chunk_len, actual;
+ struct spi_slave *spi = flash->spi;
+ unsigned long timeout = SPI_FLASH_PROG_TIMEOUT;
int ret;
- u8 cmd[4];
- page_size = flash->page_size;
+ if (buf == NULL)
+ timeout = SPI_FLASH_PAGE_ERASE_TIMEOUT;
ret = spi_claim_bus(flash->spi);
if (ret) {
@@ -84,6 +84,41 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32
offset,
return ret;
}
+ ret = spi_flash_cmd_write_enable(flash);
+ if (ret < 0) {
+ debug("SF: enabling write failed\n");
+ return ret;
+ }
+
+ ret = spi_flash_cmd_write(spi, cmd, cmd_len, buf, buf_len);
+ if (ret < 0) {
+ debug("SF: write cmd failed\n");
+ return ret;
+ }
+
+ ret = spi_flash_cmd_wait_ready(flash, timeout);
+ if (ret < 0) {
+ debug("SF: write %s timed out\n",
+ timeout == SPI_FLASH_PROG_TIMEOUT ?
+ "program" : "page erase");
+ return ret;
+ }
+
+ spi_release_bus(spi);
+
+ return ret;
+}
+
+int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 offset,
+ size_t len, const void *buf)
+{
+ unsigned long byte_addr, page_size;
+ size_t chunk_len, actual;
+ u8 cmd[4];
+ int ret = -1;
+
+ page_size = flash->page_size;
+
cmd[0] = CMD_PAGE_PROGRAM;
for (actual = 0; actual < len; actual += chunk_len) {
#ifdef CONFIG_SPI_FLASH_BAR
@@ -108,27 +143,16 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash,
u32 offset,
debug("PP: 0x%p => cmd = { 0x%02x 0x%02x%02x%02x } chunk_len =
%zu\n",
buf + actual, cmd[0], cmd[1], cmd[2], cmd[3], chunk_len);
- ret = spi_flash_cmd_write_enable(flash);
- if (ret < 0) {
- debug("SF: enabling write failed\n");
- break;
- }
-
- ret = spi_flash_cmd_write(flash->spi, cmd, 4,
- buf + actual, chunk_len);
+ ret = spi_flash_write_common(flash, cmd, sizeof(cmd),
+ buf + actual, chunk_len);
if (ret < 0) {
debug("SF: write failed\n");
break;
}
- ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
- if (ret)
- break;
-
offset += chunk_len;
}
- spi_release_bus(flash->spi);
return ret;
}
@@ -242,8 +266,8 @@ int spi_flash_cmd_wait_ready(struct spi_flash *flash,
unsigned long timeout)
int spi_flash_cmd_erase(struct spi_flash *flash, u32 offset, size_t len)
{
u32 erase_size;
- int ret;
u8 cmd[4];
+ int ret = -1;
erase_size = flash->sector_size;
if (offset % erase_size || len % erase_size) {
@@ -251,12 +275,6 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32
offset, size_t len)
return -1;
}
- ret = spi_claim_bus(flash->spi);
- if (ret) {
- debug("SF: Unable to claim SPI bus\n");
- return ret;
- }
-
if (erase_size == 4096)
cmd[0] = CMD_ERASE_4K;
else
@@ -279,24 +297,16 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32
offset, size_t len)
debug("SF: erase %2x %2x %2x %2x (%x)\n", cmd[0], cmd[1],
cmd[2], cmd[3], offset);
- ret = spi_flash_cmd_write_enable(flash);
- if (ret)
- goto out;
-
- ret = spi_flash_cmd_write(flash->spi, cmd, sizeof(cmd), NULL,
0);
- if (ret)
- goto out;
Re: [U-Boot] [PATCH v3 2/4] sf: Place the sf calls in proper order
On 21-06-2013 19:19, Jagannadha Sutradharudu Teki wrote:
From: Jagannadha Sutradharudu Teki
Placed the sf calls in proper order - erase/write/read
Signed-off-by: Jagannadha Sutradharudu Teki
---
Changes for v3:
-
Changes for v2:
-
drivers/mtd/spi/spi_flash.c | 184 ++--
1 file changed, 92 insertions(+), 92 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 03cecef..a329850 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -68,6 +68,51 @@ int spi_flash_cmd_write(struct spi_slave *spi, const u8
*cmd, size_t cmd_len,
return spi_flash_read_write(spi, cmd, cmd_len, data, NULL, data_len);
}
+int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
+{
+ struct spi_slave *spi = flash->spi;
+ unsigned long timebase;
+ int ret;
+ u8 status;
+ u8 check_status = 0x0;
+ u8 poll_bit = STATUS_WIP;
+ u8 cmd = flash->poll_cmd;
+
+ if (cmd == CMD_FLAG_STATUS) {
+ poll_bit = STATUS_PEC;
+ check_status = poll_bit;
+ }
+
+ ret = spi_xfer(spi, 8, &cmd, NULL, SPI_XFER_BEGIN);
+ if (ret) {
+ debug("SF: fail to read %s status register\n",
+ cmd == CMD_READ_STATUS ? "read" : "flag");
+ return ret;
+ }
+
+ timebase = get_timer(0);
+ do {
+ WATCHDOG_RESET();
+
+ ret = spi_xfer(spi, 8, NULL, &status, 0);
+ if (ret)
+ return -1;
+
+ if ((status & poll_bit) == check_status)
+ break;
+
+ } while (get_timer(timebase) < timeout);
+
+ spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
+
+ if ((status & poll_bit) == check_status)
+ return 0;
+
+ /* Timed out */
+ debug("SF: time out!\n");
+ return -1;
+}
+
int spi_flash_write_common(struct spi_flash *flash, const u8 *cmd,
size_t cmd_len, const void *buf, size_t buf_len)
{
@@ -109,6 +154,53 @@ int spi_flash_write_common(struct spi_flash *flash, const
u8 *cmd,
return ret;
}
+int spi_flash_cmd_erase(struct spi_flash *flash, u32 offset, size_t len)
+{
+ u32 erase_size;
+ u8 cmd[4];
+ int ret = -1;
+
+ erase_size = flash->sector_size;
+ if (offset % erase_size || len % erase_size) {
+ debug("SF: Erase offset/length not multiple of erase size\n");
+ return -1;
+ }
+
+ if (erase_size == 4096)
+ cmd[0] = CMD_ERASE_4K;
+ else
+ cmd[0] = CMD_ERASE_64K;
+
+ while (len) {
+#ifdef CONFIG_SPI_FLASH_BAR
+ u8 bank_sel;
+
+ bank_sel = offset / SPI_FLASH_16MB_BOUN;
+
+ ret = spi_flash_cmd_bankaddr_write(flash, bank_sel);
+ if (ret) {
+ debug("SF: fail to set bank%d\n", bank_sel);
+ return ret;
+ }
+#endif
+ spi_flash_addr(offset, cmd);
+
+ debug("SF: erase %2x %2x %2x %2x (%x)\n", cmd[0], cmd[1],
+ cmd[2], cmd[3], offset);
+
+ ret = spi_flash_write_common(flash, cmd, sizeof(cmd), NULL, 0);
+ if (ret < 0) {
+ debug("SF: erase failed\n");
+ break;
+ }
+
+ offset += erase_size;
+ len -= erase_size;
+ }
+
+ return ret;
+}
+
int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 offset,
size_t len, const void *buf)
{
@@ -218,98 +310,6 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32
offset,
return ret;
}
-int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
-{
- struct spi_slave *spi = flash->spi;
- unsigned long timebase;
- int ret;
- u8 status;
- u8 check_status = 0x0;
- u8 poll_bit = STATUS_WIP;
- u8 cmd = flash->poll_cmd;
-
- if (cmd == CMD_FLAG_STATUS) {
- poll_bit = STATUS_PEC;
- check_status = poll_bit;
- }
-
- ret = spi_xfer(spi, 8, &cmd, NULL, SPI_XFER_BEGIN);
- if (ret) {
- debug("SF: fail to read %s status register\n",
- cmd == CMD_READ_STATUS ? "read" : "flag");
- return ret;
- }
-
- timebase = get_timer(0);
- do {
- WATCHDOG_RESET();
-
- ret = spi_xfer(spi, 8, NULL, &status, 0);
- if (ret)
- return -1;
-
- if ((status & poll_bit) == check_status)
- break;
-
- } while (get_timer(timebase) < timeout);
-
- spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
-
- if ((status & poll_bit) == check_status)
- return 0;
-
- /* Timed out */
- debug("SF: time out!\n")
Re: [U-Boot] [PATH v5 00/14] sf: Update sf framework to support all sizes of flashes
On 21-06-2013 20:12, Jagannadha Sutradharudu Teki wrote: This is a v5 patch series with some modifications on previous series with same head "sf: Update sf framework to support all sizes of flashes" The current implementation in sf supports 3-byte address mode due to this up to 16MB amount of flash is able to access for those flashes which has an actual size of > 16MB. This series of patches is more detailed/meatured changes w.r.t the current sf framework in addition to changes related to support all sizes using bank/exnt register addr accessing support. With these new updates on sf framework, the flashes which has < 16MB are not effected as per as performance is concern and but the u-boot.bin size incrased ~460 bytes. sf update(for first 16MBytes), Changes before: U-Boot> sf update 0x100 0x0 0x100 - N25Q256 16777216 bytes written, 0 bytes skipped in 199.72s, speed 86480 B/s - W25Q128BV 16777216 bytes written, 0 bytes skipped in 351.739s, speed 48913 B/s - S25FL256S_64K 16777216 bytes written, 0 bytes skipped in 65.659s, speed 262144 B/s sf update(for first 16MBytes), Changes after: U-Boot> sf update 0x100 0x0 0x100 - N25Q256 16777216 bytes written, 0 bytes skipped in 198.953s, speed 86480 B/s - W25Q128BV 16777216 bytes written, 0 bytes skipped in 350.90s, speed 49200 B/s - S25FL256S_64K 16777216 bytes written, 0 bytes skipped in 66.521s, speed 262144 B/s The main aim of these changes is to not effect the current framework and at the same time to support the > 16Mbyte flashes, becuase of this I involved few flash vendor people in CC [thought that they may/mayn't be a mailing list members] to know their views. REQUEST FOR ALL SPI CODE CONTRIBUTORS/USERS, PLEASE TEST THESE CHANGES W.R.T YOUR HW IF POSSIBLE. Please let me know for any issues/concerns/questions. -- Thanks, Jagan. Jagannadha Sutradharudu Teki (14): sf: Add bank address register writing support sf: Discover the bank addr commands sf: Read flash bank addr register at probe time sf: Update sf to support all sizes of flashes sf: Update sf read to support all sizes of flashes sf: Add bank addr code in CONFIG_SPI_FLASH_BAR sf: Use spi_flash_addr() in write call sf: stmicro: Add support for N25Q512 sf: stmicro: Add support for N25Q512A sf: stmicro: Add support for N25Q1024 sf: stmicro: Add support for N25Q1024A sf: spansion: Add support for S25FL512S_64K sf: Remove spi_flash_cmd_poll_bit() sf: Add flag status register polling support README | 5 + drivers/mtd/spi/spansion.c | 7 ++ drivers/mtd/spi/spi_flash.c | 186 +-- drivers/mtd/spi/spi_flash_internal.h | 29 +- drivers/mtd/spi/stmicro.c| 28 ++ include/spi_flash.h | 10 ++ 6 files changed, 232 insertions(+), 33 deletions(-) Applied to u-boot-spi/master -- Thanks, Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, These are the major updates on current spi_flash framework to support all sizes of flashes in 3-byte addressing mode. Tested these changes on stmicro, winbond and spansion flashes. Thanks, Jagan. The following changes since commit 7315cfd9e1922ee1c3c5f016e5a3b16199122172: NET: Fix system hanging if NET device is not installed (2013-06-19 08:32:44 -0400) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to b9e31be0f8adc1a55179ae3b45c9e274f4650007: sf: Warn to use BAR for > 16MiB flashes (2013-06-23 22:10:36 +0530) Axel Lin (2): spi: cf_qspi: Use DIV_ROUND_UP at appropriate place spi: mxc_spi: Use DIV_ROUND_UP at appropriate places Jagannadha Sutradharudu Teki (23): sf: spansion: Correct name of S25FL128S 64K Sector part sf: winbond: Update the names for W25Q 0x40XX ID's flash parts sf: winbond: Add support for W25Q128FW sf: winbond: Add support for W25Q16DW sf: winbond: Add support for W25QXXXFV sf: Add bank address register writing support sf: Discover the bank addr commands sf: Read flash bank addr register at probe time sf: Update sf to support all sizes of flashes sf: Update sf read to support all sizes of flashes sf: Add bank addr code in CONFIG_SPI_FLASH_BAR sf: Use spi_flash_addr() in write call sf: stmicro: Add support for N25Q512 sf: stmicro: Add support for N25Q512A sf: stmicro: Add support for N25Q1024 sf: stmicro: Add support for N25Q1024A sf: spansion: Add support for S25FL512S_64K sf: Remove spi_flash_cmd_poll_bit() sf: Add flag status register polling support sf: Unify spi_flash write code sf: Place the sf calls in proper order sf: Add debug messages on spi_flash_read_common sf: Warn to use BAR for > 16MiB flashes README | 5 + drivers/mtd/spi/spansion.c | 9 +- drivers/mtd/spi/spi_flash.c | 376 +++ drivers/mtd/spi/spi_flash_internal.h | 39 +++- drivers/mtd/spi/stmicro.c| 28 +++ drivers/mtd/spi/winbond.c| 24 ++- drivers/spi/cf_qspi.c| 2 +- drivers/spi/mxc_spi.c| 6 +- include/spi_flash.h | 10 + 9 files changed, 360 insertions(+), 139 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-pxa/master
On 06/23/2013 03:13 AM, Albert ARIBAUD wrote: > Hi Marek, > >>> FYI, I am using the ARM cross-toolchain available in my Ubuntu 13.04. >> >> For some reason, I feel the linaro ones were always stuffed with >> experimental >> and semi-broken stuff :-( > > Maybe they were; all I can say is, the Ubuntu/Linaro toolchain never > failed me in any way. I build my toolchain using the crossdev script, which is a gentoo package. I've been doing this for years without any problems, except that occasionally building requires some trial-and-error because of incompatibilities between gcc/binutils/glibc. But other than that, I am able to choose the version of each tool. Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 03/14] net: add Faraday FTMAC110 10/100Mbps ethernet support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/23/2013 09:18 AM, Albert ARIBAUD wrote: > Hi Tom, > > On Sun, 23 Jun 2013 07:09:49 -0400, Tom Rini wrote: > >> On Sun, Jun 23, 2013 at 09:18:11AM +0200, Albert ARIBAUD wrote: >>> Hi Kuo-Jung, >>> >>> On Mon, 17 Jun 2013 20:06:53 +0800, Kuo-Jung Su >>> wrote: >>> NOTE: No matter if MMU/D-cache is on or off, this patch always depends on previous patch: arm: dma_alloc_coherent: malloc() -> memalign(). Because the FTMAC110 expects the tx/rx descriptors are always be aligned to 16-bytes boundary. >>> >>> Ditto patch 01/14. > > Actually I meant 02/14, as 01/14 is the patch upon which 02 and 03 > depend. > >> Hasn't hit the list yet :) > > Hmm... Gmane has the full series, and so has patchwork. > > Or did I miss a joke/pun/other(please specify)? No, I just assumed you had a comment in 1/14, hadn't looked at the whole thing yet. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRxxGDAAoJENk4IS6UOR1WhFIP/2VWO75krgx9OPR0j5uf7NXl HmcGzctPU1eyxQs5Ss7YgaZueo3dZ76+2zboJ/Y/PfjXjKyWvh2i7BsILElhr1CJ ufhtS35/Gfi4jvxokMf2w5KTcahXq6SGgo4C8sUc85NfIscnMnWROaFFVe8LiInq DchFQiqEN1yTJr/nyTnjV/BjHg9L2piXRmTrdxtDjQIYI2Fi7WLIRYTbfqeWwLZ4 AvWwCIh7mDzHM1QQ/+pVsNjJvDZS0Ae1NsM9JS7QRjPlBHVECt/AWqxMnSYsZFfa A7FyZyBzVtfp3QHYP2jQnS6ZcE4ErYd4aorrnvN4TMmaWzl0jcD3HeCf40SWGAVm HFzvANj530C3XyPSHHVyCjAGc9ijNO6K9vVZCJpsYceyM3OLMArwIWnuYwFQfqSN kmhbfOfbSOQhNaiECaZOkSlZEymq1//F25hr1uF0T8nQfXMZMh64NcOyXTysBhX3 WpCpujp/eAywpZaK40Odu2bBiVsSsBtdxkhQACcyIp1bnJslioE3GXEWmwBShP5A O1a09a3MZG+chAZgiLK4a12JqqapMO2so6Dq7CEw7See/Xkg0WkeTt7NtwTFPlvK R5x6gfr5EkE0uBWLAr8yJ4HtmUJY4BnlRqXxTYA2Za6d6x5vgIFgkDjQccnPD0JA 8pOaSTargAx7Y1PwZvPG =X+XJ -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 03/14] net: add Faraday FTMAC110 10/100Mbps ethernet support
Hi Tom, On Sun, 23 Jun 2013 07:09:49 -0400, Tom Rini wrote: > On Sun, Jun 23, 2013 at 09:18:11AM +0200, Albert ARIBAUD wrote: > > Hi Kuo-Jung, > > > > On Mon, 17 Jun 2013 20:06:53 +0800, Kuo-Jung Su > > wrote: > > > > > NOTE: > > > No matter if MMU/D-cache is on or off, this patch > > > always depends on previous patch: > > > > > > arm: dma_alloc_coherent: malloc() -> memalign(). > > > > > > Because the FTMAC110 expects the tx/rx descriptors > > > are always be aligned to 16-bytes boundary. > > > > Ditto patch 01/14. Actually I meant 02/14, as 01/14 is the patch upon which 02 and 03 depend. > Hasn't hit the list yet :) Hmm... Gmane has the full series, and so has patchwork. Or did I miss a joke/pun/other(please specify)? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 03/14] net: add Faraday FTMAC110 10/100Mbps ethernet support
On Sun, Jun 23, 2013 at 09:18:11AM +0200, Albert ARIBAUD wrote: > Hi Kuo-Jung, > > On Mon, 17 Jun 2013 20:06:53 +0800, Kuo-Jung Su > wrote: > > > NOTE: > > No matter if MMU/D-cache is on or off, this patch > > always depends on previous patch: > > > > arm: dma_alloc_coherent: malloc() -> memalign(). > > > > Because the FTMAC110 expects the tx/rx descriptors > > are always be aligned to 16-bytes boundary. > > Ditto patch 01/14. Hasn't hit the list yet :) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-pxa/master
Hi Marek, > > FYI, I am using the ARM cross-toolchain available in my Ubuntu 13.04. > > For some reason, I feel the linaro ones were always stuffed with experimental > and semi-broken stuff :-( Maybe they were; all I can say is, the Ubuntu/Linaro toolchain never failed me in any way. > Best regards, > Marek Vasut Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-pxa/master
Dear Albert ARIBAUD, > Hi Mike, > > On Sat, 22 Jun 2013 10:42:27 -0700, Mike Dunn > > wrote: > > On 06/22/2013 09:57 AM, Albert ARIBAUD wrote: > > > Hi Marek, > > > > > > On Sat, 22 Jun 2013 15:26:21 +0200, Marek Vasut wrote: > > >> The following changes since commit fbf87b1823dd5ebc2a384711ea2c677543019ece: > > >> arm: optimize relocate_code routine (2013-06-21 23:05:50 +0200) > > >> > > >> are available in the git repository at: > > >> git://git.denx.de/u-boot-pxa.git master > > >> > > >> for you to fetch changes up to 9dc8fef2583f23ca6a99c6f5e709a8b80018364f: > > >> pxa: fix memory coherency problem after relocation (2013-06-22 > > >> 15:25:28 +0200) > > >> > > >> > > >> > > >> Mike Dunn (5): > > >> pxa: add support for palmtreo680 board > > >> pxa: palmtreo680 flash programming utility > > >> pxa: turn icache off in cpu_init_crit() > > >> pxa: use -mcpu=xscale compiler option > > >> pxa: fix memory coherency problem after relocation > > >> > > >> CREDITS |4 + > > >> MAINTAINERS |3 + > > >> arch/arm/cpu/pxa/config.mk |2 +- > > >> arch/arm/cpu/pxa/start.S |3 +- > > >> arch/arm/lib/relocate.S |9 +++ > > >> board/palmtreo680/Makefile | 34 + > > >> board/palmtreo680/README | 581 > > >> > > >> ++ > > >> > > >> > > >> board/palmtreo680/palmtreo680.c | 148 > > >> +++ boards.cfg > > >> |1 + > > >> include/configs/palmtreo680.h| 286 > > >> > > >> > > >> > > >> tools/palmtreo680/flash_u-boot.c | 177 > > >> > > >> ++ > > >> > > >> 11 files changed, 1245 insertions(+), 3 deletions(-) > > >> create mode 100644 board/palmtreo680/Makefile > > >> create mode 100644 board/palmtreo680/README > > >> create mode 100644 board/palmtreo680/palmtreo680.c > > >> create mode 100644 include/configs/palmtreo680.h > > >> create mode 100644 tools/palmtreo680/flash_u-boot.c > > > > > > gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) > > > > > fails with warnings for palmtreo680: > > I don't get these warnings, despite the u-boot makefiles passing -Wall to > > gcc. I'm using gcc version 4.5.4... I guess maybe I need to update gcc > > because later versions are stricter? I'll go ahead and do that, and if > > this produces the warnings, I'll submit patches that eliminates them. > > Sorry. > > No need to be sorry -- you were using a toolchain that does not emit > these warnings, so you could not be expected to see them. > > FYI, I am using the ARM cross-toolchain available in my Ubuntu 13.04. For some reason, I feel the linaro ones were always stuffed with experimental and semi-broken stuff :-( Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/8] Provide a mechanism to avoid using #ifdef everywhere
Hi Simon, On Mon, 17 Jun 2013 07:44:52 -0700, Simon Glass wrote: > Note that a config_drop.h file is added - this defines all the CONFIGs > which are not used in any board config file. Without this, autoconf cannot > define the macros for this CONFIGs. > > Compile time for main.c does not seem to be any different in my tests. The > time to perform the 'dep' step (which now creates autoconf.h) increases, > from about 2.8s to about 4.6s. This additional time is used to grep, sed > and sort the contents of all the header file in U-Boot. The time for an > incremental build is not affected. > > It would be much more efficient to maintain a list of all available CONFIG > defines, but no such list exists at present. Stop me if I am wrong, but do you not have this list already, since at one point you grep, sed and sort the whole list of config options, then at another point generate the list of unused ones? Granted, that's the list of config options defined, not necessarily the list of options used, but a second variation of the grep/sed/sort might give you a hint on that. Plus, I would love having scripts in tools/ that look for either defined or used config options. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 12/14] arm: add Faraday specific boot command
Hi Kuo-Jung, On Mon, 17 Jun 2013 20:07:02 +0800, Kuo-Jung Su wrote: > From: Kuo-Jung Su > > At the time of writting, none of Faraday NAND & SPI controllers > supports XIP (eXecute In Place). So the Faraday A360/A369 SoC has > to implement a 1st level bootstrap code stored in the embedded ROM > inside the SoC. > > After power-on, the ROM code (1st level bootstrap code) would load > the 2nd bootstrap code into SRAM without any SDRAM initialization. > > The 2nd bootstrap code would then initialize SDRAM and load the > generic firmware (u-boot/linux) into SDRAM, and finally make > a long-jump to the firmware. > > Which means the SPL design of U-boot would never fit to A360/A369, > since it's usually not possible to alter a embedded ROM code. > And because both the 1st & 2nd level bootstrap code use the private > Faraday Firmware Image Format, it would be better to drop U-boot > image support to simplify the design. Please reword the last sentence: you're not suggesting "to drop U-boot support" from U-Boot, right? You're only suggesting adding the Faraday image format. Also, maybe the long explanation should go in the cover letter and a single shorter paragraph should be given as commit message here. > Signed-off-by: Kuo-Jung Su > CC: Albert Aribaud > --- Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 03/14] net: add Faraday FTMAC110 10/100Mbps ethernet support
Hi Kuo-Jung, On Mon, 17 Jun 2013 20:06:53 +0800, Kuo-Jung Su wrote: > NOTE: > No matter if MMU/D-cache is on or off, this patch > always depends on previous patch: > > arm: dma_alloc_coherent: malloc() -> memalign(). > > Because the FTMAC110 expects the tx/rx descriptors > are always be aligned to 16-bytes boundary. Ditto patch 01/14. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 02/14] net: ftgmac100: add MMU/D-cache support
Hi Kuo-Jung, On Mon, 17 Jun 2013 20:06:52 +0800, Kuo-Jung Su wrote: > 3. No matter if MMU/D-cache is on or off, this patch >always depends on previous patch: > >arm: dma_alloc_coherent: malloc() -> memalign(). > >Because the FTGMAC100 expects the tx/rx descriptors >are always be aligned to 16-bytes boundary. Nitpick: as a general rule, the commit message does not need to mention that a patch in a series depends on a previous one; this is implied by the series itself. In fact, it should even /refrain/ from doing so because even though the series is usually applied atomically, it is not impossible that a an unrelated 'hot' bugfix patch slip in the middle of it, so "previous patch", which makes sense at submission time, might not make sense any more later. Personally I like the commit message to only provide a short explanation of the whys and hows of the patch itself, and put any additional info after the commit message separator "---" below or, if using patman, in the cover letter. > Signed-off-by: Kuo-Jung Su > CC: Albert ARIBAUD > CC: Joe Hershberger > CC: Tom Rini > --- > Changes for v5: Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/bsc913x: Add config flag for bootdelay
Hi Harninder, On Mon, 17 Jun 2013 17:18:32 +0530, Harninder Rai wrote: > Keep the value of CONFIG_BOOTDELAY as -1 to disable autoboot > > Signed-off-by: Harninder Rai > --- > include/configs/BSC9131RDB.h |1 + > include/configs/BSC9132QDS.h |1 + > 2 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/include/configs/BSC9131RDB.h b/include/configs/BSC9131RDB.h > index fd076e0..c56b119 100644 > --- a/include/configs/BSC9131RDB.h > +++ b/include/configs/BSC9131RDB.h > @@ -393,6 +393,7 @@ extern unsigned long get_sdram_size(void); > #define CONFIG_UBOOTPATH "u-boot.bin" /* U-Boot image on TFTP server */ > > #define CONFIG_BAUDRATE 115200 > +#define CONFIG_BOOTDELAY -1 /* Disable autoboot */ > > #define CONFIG_EXTRA_ENV_SETTINGS \ > "netdev=eth0\0" \ > diff --git a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h > index 9d15d0e..d54900a 100644 > --- a/include/configs/BSC9132QDS.h > +++ b/include/configs/BSC9132QDS.h > @@ -607,6 +607,7 @@ combinations. this should be removed later > #define CONFIG_UBOOTPATH "u-boot.bin" > > #define CONFIG_BAUDRATE 115200 > +#define CONFIG_BOOTDELAY -1 /* Disable autoboot */ > > #ifdef CONFIG_SDCARD > #define CONFIG_DEF_HWCONFIG "hwconfig=usb1:dr_mode=host,phy_type=ulpi\0" Plase fix commit message: you're not simply adding a boot delay flag, you're in fact disabling autoboot, which is quite different. Also, when touching on a board's code, you should Cc: the board's maintainer(s). Please do so for V2 of your patch -- and if you get a non-delivery status (e.g. a maintainer's mail address does not exist any more), please follow up on your patch submission to let us know. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
