Re: [U-Boot] [PATCH v4] i2c: s3c24xx: add hsi2c controller support
Hello Naveen Krishna, On 13.04.2013 06:42, Naveen Krishna Ch wrote: On 6 April 2013 07:07, Naveen Krishna Chatradhi wrote: Add support for hsi2c controller available on exynos5420. Note: driver currently supports only fast speed mode 100kbps Change-Id: I02555b1dc8f4ac21c50aa5158179768563c92f43 Signed-off-by: Naveen Krishna Chatradhi Signed-off-by: R. Chandrasekar Reviewed-by: Vadim Bendebury Reviewed-by: Simon Glass --- Changes since v3: 1. Implemented get_timer instead of while and udelay for master busy function 2. Use reg base address from device tree 3. Split the timing function to check for the errors 4. Implemented reset function for to recover from failure cases 5. Implemented a comat string for hsi2c to distingush the channels 6. Minor cosmotic changes Note: FIFOs will be implemented in subsequent patches drivers/i2c/s3c24x0_i2c.c | 494 + drivers/i2c/s3c24x0_i2c.h | 36 2 files changed, 486 insertions(+), 44 deletions(-) [...] -- 1.7.9.5 Hello all i got it review by Simon and Vadim. Any updates on this driver please As this patch in patchwork is in the responsibilty of Minkyu Kang (why?, added to cc): Reviewed-by: Heiko Schocher Acked-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot newbie question on booting ep405 board
Dear David Li, In message you wrote: > > I am new to using uBoot and learning with a EP405 board. Which exact board is this? > Basically I built the Linux uImage and device tree blob for EP 405. > Both were downloaded on to RAM - uImage at memory 0x20 and > ep405.dtb at 0x400. Note that these addresses are way too low in any case. > When I used "bootm" to boot the > kernel, I always get "Bad Magic Number" like this: > > > => bootm 0x200 - 0x400 > ## Booting image at 0200 ... >Image Name: Linux-3.7.8 >Image Type: PowerPC Linux Kernel Image (gzip compressed) >Data Size:2571848 Bytes = 2.5 MB Even your compressed kernel is bigger than the 2 MB where you load it; when uncompressing, it will overwrite both the tail of the UImage itself, and the DTB. > ## Loading RAMDisk Image at ... > Bad Magic Number Did you now wonder why it's talking about a ramdisk here? You did not pass a ramdisk address (at least you did not mean to). > U-Boot 1.2.0-gd35b508a-dirty (Sep 19 2007 - 14:13:23) > > What's wrong? Why it's loading ramdisk at 000? I built the kernel > and initramfs together in the uImage. Your U-Boot is more than 6 years old; that is not only stone age, but even long before the introduction of device tree support. You cannot use this ancient U-Boot version to boot a recent LInux kernel with device tree support. PLease update to a recent U-Boot version, or stick with Linux kernel versions of similar age, i. e. something like v2.6.19 or v.2.6.20 (yes, this is old crap, but so is your version of U-Boot). 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 We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] uboot newbie question on booting ep405 board
Hi, I am new to using uBoot and learning with a EP405 board. The board is up with the original uBoot that comes with it. But I have encountered some problems booting up Linux. I wonder if anyone can give me some hint or help what went wrong. Basically I built the Linux uImage and device tree blob for EP 405. Both were downloaded on to RAM - uImage at memory 0x20 and ep405.dtb at 0x400. When I used "bootm" to boot the kernel, I always get "Bad Magic Number" like this: => bootm 0x200 - 0x400 ## Booting image at 0200 ... Image Name: Linux-3.7.8 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:2571848 Bytes = 2.5 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading RAMDisk Image at ... Bad Magic Number U-Boot 1.2.0-gd35b508a-dirty (Sep 19 2007 - 14:13:23) What's wrong? Why it's loading ramdisk at 000? I built the kernel and initramfs together in the uImage. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exynos5: Add support for USB download boot mode
Hi,
On Sat, Apr 13, 2013 at 7:50 PM, Simon Glass wrote:
> Hi,
>
> On Tue, Feb 5, 2013 at 9:04 PM, Vivek Gautam
> wrote:
>> Hi Simon,
>>
>>
>> On Tue, Feb 5, 2013 at 2:56 AM, Simon Glass wrote:
>>> Hi,
>>>
>>> On Mon, Jan 28, 2013 at 2:39 AM, Vivek Gautam
>>> wrote:
Exynos5250 supports secondary USB device boot mode. If the iROM fails
to download u-boot from the primary boot device (such as SD or eMMC),
it will try to retrieve from the secondary boot device (such as USB).
Signed-off-by: Naveen Krishna Ch
Signed-off-by: Simon Glass
Signed-off-by: Vivek Gautam
>>>
>>> Acked-by: Simon Glass
>>>
>>
>> Thanks for reviewing.
>>
>>> But please see comment below.
>>>
---
NOTE:
- Based on 'master' branch of u-boot-samsung.
- Tested with smdk5250 for usb download mode.
board/samsung/smdk5250/spl_boot.c | 40
+++-
include/configs/exynos5250-dt.h |5
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/board/samsung/smdk5250/spl_boot.c
b/board/samsung/smdk5250/spl_boot.c
index d8f3c1e..c0bcf46 100644
--- a/board/samsung/smdk5250/spl_boot.c
+++ b/board/samsung/smdk5250/spl_boot.c
@@ -32,6 +32,21 @@ enum boot_mode {
};
typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
+ typedef u32 (*usb_copy_func_t)(void);
+
+/*
+ * Set/clear program flow prediction and return the previous state.
+ */
+static int config_branch_prediction(int set_cr_z)
+{
+ unsigned int cr;
+
+ /* System Control Register: 11th bit Z Branch prediction enable */
+ cr = get_cr();
+ set_cr(set_cr_z ? cr | CR_Z : cr & ~CR_Z);
+
+ return cr & CR_Z;
+}
/*
* Copy U-boot from mmc to RAM:
@@ -41,10 +56,20 @@ enum boot_mode {
void copy_uboot_to_ram(void)
{
spi_copy_func_t spi_copy;
- enum boot_mode bootmode;
+ usb_copy_func_t usb_copy;
+
+ int is_cr_z_set;
+ unsigned int sec_boot_check;
+ enum boot_mode bootmode = BOOT_MODE_OM;
u32 (*copy_bl2)(u32, u32, u32);
- bootmode = readl(EXYNOS5_POWER_BASE) & OM_STAT;
+ /* Read iRAM location to check for secondary USB boot mode */
+ sec_boot_check = readl(EXYNOS_IRAM_SECONDARY_BASE);
+ if (sec_boot_check == EXYNOS_USB_SECONDARY_BOOT)
+ bootmode = BOOT_MODE_USB;
+
+ if (bootmode == BOOT_MODE_OM)
+ bootmode = readl(EXYNOS5_POWER_BASE) & OM_STAT;
switch (bootmode) {
case BOOT_MODE_SERIAL:
@@ -57,6 +82,17 @@ void copy_uboot_to_ram(void)
copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT,
CONFIG_SYS_TEXT_BASE);
break;
+ case BOOT_MODE_USB:
+ /*
+* iROM needs program flow prediction to be disabled
+* before copy from USB device to RAM
+*/
+ is_cr_z_set = config_branch_prediction(0);
+ usb_copy = *(usb_copy_func_t *)
+ EXYNOS_COPY_USB_FNPTR_ADDR;
+ usb_copy();
+ config_branch_prediction(is_cr_z_set);
+ break;
default:
break;
}
diff --git a/include/configs/exynos5250-dt.h
b/include/configs/exynos5250-dt.h
index cabd2f2..6728b0e 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -123,6 +123,11 @@
#define CONFIG_USB_EHCI_EXYNOS
#define CONFIG_USB_STORAGE
+/* USB boot mode */
+#define EXYNOS_COPY_USB_FNPTR_ADDR 0x02020070
+#define EXYNOS_USB_SECONDARY_BOOT 0xfeed0002
+#define EXYNOS_IRAM_SECONDARY_BASE 0x02020018
>>>
>>>
>>> What happened to the function pointer table patch?
>>>
>> I think i missed that patch from Amar, :-(
>> will remove these #defines and use the function pointer table instead.
>
> I notice that this patch has not made it to mainline. It really should
> be there since without it it is not possible to USB boot on snow,
> which makes development awkward.
>
> Can we get this applied in time for the release? The comment made
> above can be dealt with later perhaps.
Sorry for not responding to this patch for long, but was still waiting
for Amar's emmc booting patch
to get merged (which carries the funtion pointer table).
Hi Minkyu,
Is it fine with you if we pull this in for now, and post a patch later
to make things aligned
with funtion-pointer table ?
This patch cleanly applies on u-boot-samsung/master.
--
Thanks & Regards
Vivek
_
Re: [U-Boot] [PATCH 0/5] vybrid: Add vybrid CPU and vf600 tower board support
>-Original Message- >From: Wang Huan-B18965 >Sent: Friday, April 12, 2013 2:54 PM >To: u-boot@lists.denx.de >Cc: sba...@denx.de; Liu Hui-R64343; Estevam Fabio-R49496 >Subject: [PATCH 0/5] vybrid: Add vybrid CPU and vf600 tower board >support > >This series contains the support for vybrid CPU and vf600 tower board. > >The Vybrid devices are a family of Freescale's latest Dual Single Core >offering with ARM Cortex A5 and CM4 based processors for Advanced >Connected Radio, Entry Infotainment, and Cluster as well as high end >industrial and general purpose applications. > > >Alison Wang (5): > vybrid: add vybrid CPU support > vybrid: add Freescale vybrid vf600 tower board support > vybrid: add uart driver support > vybrid: add eSDHC driver support > vybrid: add ethernet driver support Typically, the sequence for the new CPU/board support is: - CPU MSL support (clock/iomux/gpio/low level init/ - Driver support, - Board support, Jason Liu > > Makefile | 8 ++ > arch/arm/cpu/armv7/vybrid-common/Makefile| 46 +++ > arch/arm/cpu/armv7/vybrid-common/cpu.c | 127 >++ > arch/arm/cpu/armv7/vybrid-common/speed.c | 37 + > arch/arm/cpu/armv7/vybrid-common/timer.c | 140 >+++ > arch/arm/cpu/armv7/vybrid/Makefile | 45 +++ > arch/arm/cpu/armv7/vybrid/asm-offsets.c | 70 ++ > arch/arm/cpu/armv7/vybrid/clock.c| 278 >++ > arch/arm/cpu/armv7/vybrid/iomux.c| 42 ++ > arch/arm/cpu/armv7/vybrid/lowlevel_init.S| 128 >++ > arch/arm/cpu/armv7/vybrid/soc.c | 42 ++ > arch/arm/include/asm/arch-vybrid/clock.h | 41 ++ > arch/arm/include/asm/arch-vybrid/iomux.h | 323 > > arch/arm/include/asm/arch-vybrid/serial-vybrid.h | 213 >+ > arch/arm/include/asm/arch-vybrid/sys_proto.h | 30 + > arch/arm/include/asm/arch-vybrid/timer.h | 405 >+++ > arch/arm/include/asm/arch-vybrid/vybrid-pins.h | 88 > arch/arm/include/asm/arch-vybrid/vybrid-regs.h | 735 > > > arch/arm/include/asm/fec.h | 302 >+ > arch/arm/include/asm/global_data.h | 3 + > arch/arm/include/asm/mach-types.h| 56 > arch/arm/include/asm/u-boot.h| 3 + > board/freescale/vybrid/Makefile | 40 ++ > board/freescale/vybrid/vybrid.c | 488 >++ > board/freescale/vybrid/vybridimage.cfg | 44 ++ > boards.cfg | 2 + > drivers/mmc/fsl_esdhc.c | 4 +- > drivers/net/mcffec.c | 18 ++- > drivers/net/mcfmii.c | 5 +- > drivers/serial/Makefile | 1 + > drivers/serial/serial.c | 2 + > drivers/serial/serial_vybrid.c | 129 >++ > include/configs/vybrid.h | 284 >+++ > include/configs/vybrid_iram.h| 284 >+++ > 34 files changed, 4455 insertions(+), 8 deletions(-) create mode >100644 arch/arm/cpu/armv7/vybrid-common/Makefile > create mode 100644 arch/arm/cpu/armv7/vybrid-common/cpu.c > create mode 100644 arch/arm/cpu/armv7/vybrid-common/speed.c > create mode 100644 arch/arm/cpu/armv7/vybrid-common/timer.c > create mode 100644 arch/arm/cpu/armv7/vybrid/Makefile > create mode 100644 arch/arm/cpu/armv7/vybrid/asm-offsets.c > create mode 100644 arch/arm/cpu/armv7/vybrid/clock.c create mode >100644 arch/arm/cpu/armv7/vybrid/iomux.c create mode 100644 >arch/arm/cpu/armv7/vybrid/lowlevel_init.S > create mode 100644 arch/arm/cpu/armv7/vybrid/soc.c create mode 100644 >arch/arm/include/asm/arch-vybrid/clock.h > create mode 100644 arch/arm/include/asm/arch-vybrid/iomux.h > create mode 100644 arch/arm/include/asm/arch-vybrid/serial-vybrid.h > create mode 100644 arch/arm/include/asm/arch-vybrid/sys_proto.h > create mode 100644 arch/arm/include/asm/arch-vybrid/timer.h > create mode 100644 arch/arm/include/asm/arch-vybrid/vybrid-pins.h > create mode 100644 arch/arm/include/asm/arch-vybrid/vybrid-regs.h > create mode 100644 arch/arm/include/asm/fec.h create mode 100644 >board/freescale/vybrid/Makefile create mode 100644 >board/freescale/vybrid/vybrid.c create mode 100644 >board/freescale/vybrid/vybridimage.cfg > create mode 100644 drivers/serial/serial_vybrid.c create mode 100644 >include/configs
Re: [U-Boot] [PATCH 0/4] imx: Add iMX6 NAND support
Dear Stefan Roese, > Hi Marek, > > On 10.04.2013 10:21, Marek Vasut wrote: > >> To support NAND on the iMX6 this patch moves some headers into > >> i.MX common locations. Instead of creating new files in the imx6 > >> include directory containing nearly the same content. > > > >> Here the diffstat: > > They look reasonable, can you give them a test on m28evk please? > > Yes. Unfortunately it doesn't boot to the prompt. But this is not a > problem of my patchset. It also happens with the latest master branch: > > U-Boot 2013.04-rc2-00031-gfac150e (Apr 11 2013 - 11:24:25) > > CPU: Freescale i.MX28 rev1.2 at 454 MHz > > Here it hangs!!! :-( > > You are the m28 expert, so perhaps you might want to take a look? ;) I just tested latest u-boot/master on M28EVK_V20 (baseboard) + M28 V2.0 (module) , works like a charm. 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 v2 0/7] palm treo 680 smartphone board support
Dear Mike Dunn, > On 04/14/2013 10:44 AM, Marek Vasut wrote: > > Hi Mike, > > > >> Hi, > >> > >> This patchset adds support for the Palm Treo 680 smartphone. I had to > >> make some minor tweaks to u-boot to get things working. Most of these > >> changes are small, and most only touch the pxa arch. > >> > >> Thanks for looking. > > > > I pushed what I considered ok to u-boot-pxa/master, please start your > > reworks on top of that. > > Will do. Thanks a lot for your time and effort in reviewing! > > I forgot to add 'v3' to the subject line of patch 5/8 in the last set I > sent: > > [PATCH 5/8] lib: import bitrev library from the linux kernel > > Don't know if that will cause problems or not. The contents of the patch > are unchanged from v2, but the description added the HEAD commit from the > kernel I took the code from, as we discussed. Don't worry, I picked most of them already. 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/8] arm: bootm: call udc_disable() before booting linux
Dear Albert ARIBAUD, > Hi Mike, > > On Fri, 12 Apr 2013 11:59:16 -0700, Mike Dunn > > wrote: > > On the pxa270, if the udc device is not disabled before jumping to linux, > > the device fails to initialize in linux because it was left in a running > > state, and the linux driver assumes that it is in a disabled state. > > > > Signed-off-by: Mike Dunn > > --- > > > > Changelog: > > v3: no change > > v2: no change > > > > Arguably, this is a bug in the linux driver, but it seemed pretty simple > > and benign to just disable it in u-boot. I'll also send a patch to > > upstream kernel to fix its driver. > > > > arch/arm/include/asm/bootm.h |1 + > > arch/arm/lib/bootm.c |1 + > > 2 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/include/asm/bootm.h b/arch/arm/include/asm/bootm.h > > index db2ff94..68189cc 100644 > > --- a/arch/arm/include/asm/bootm.h > > +++ b/arch/arm/include/asm/bootm.h > > @@ -21,6 +21,7 @@ > > > > #ifdef CONFIG_USB_DEVICE > > extern void udc_disconnect(void); > > > > +extern void udc_disable(void); > > > > #endif > > > > #endif > > > > diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c > > index f3b30c5..6daa7bf 100644 > > --- a/arch/arm/lib/bootm.c > > +++ b/arch/arm/lib/bootm.c > > @@ -105,6 +105,7 @@ static void announce_and_cleanup(void) > > > > #ifdef CONFIG_USB_DEVICE > > > > udc_disconnect(); > > > > + udc_disable(); > > > > #endif > > > > cleanup_before_linux(); > > > > } > > Acked-By: Albert ARIBAUD Tom, will this not break any of your musb-toys? 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 v2 0/7] palm treo 680 smartphone board support
On 04/14/2013 10:44 AM, Marek Vasut wrote: > Hi Mike, > >> Hi, >> >> This patchset adds support for the Palm Treo 680 smartphone. I had to make >> some minor tweaks to u-boot to get things working. Most of these changes >> are small, and most only touch the pxa arch. >> >> Thanks for looking. > > I pushed what I considered ok to u-boot-pxa/master, please start your reworks > on > top of that. Will do. Thanks a lot for your time and effort in reviewing! I forgot to add 'v3' to the subject line of patch 5/8 in the last set I sent: [PATCH 5/8] lib: import bitrev library from the linux kernel Don't know if that will cause problems or not. The contents of the patch are unchanged from v2, but the description added the HEAD commit from the kernel I took the code from, as we discussed. Thanks again, Mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm/master
Hi Tom, The following changes since commit 785881f775252940185e10fbb2d5299c9ffa6bce: env: Add redundant env support to UBI env (2013-04-11 15:52:55 -0400) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 8960af8ba9488fc54e2e4733cbada26d3cece225: cosmetic: fix CONFIG_SPL_BSS_MAX_SIZE typo in README (2013-04-14 17:04:43 +0200) Abbas Raza (1): mmc: i.MX6: fsl_esdhc: Define maximum bus width supported by a board Ajay Kumar (13): video: exynos_fb: Remove callbacks from the driver video: exynos_dp: Remove callbacks from the driver video: exynos_fb: Make fimd_ctrl global EXYNOS: FDT: Add compatible strings for FIMD video: exynos_fb: add DT support for FIMD driver EXYNOS5: Add device node for FIMD SMDK5250: Add device node for FIMD video: exynos_dp: Make dp_regs global EXYNOS5: FDT: Add compatible strings for FIMD video: exynos_dp: Add function to parse DP DT node EXYNOS5: Add device node for DP SMDK5250: Add device node for DP SMDK5250: Use statically defined structures only in non DT case Akshay Saraswat (8): Exynos: clock: Fix a bug in PLL lock check condition Exynos: Add hardware accelerated SHA256 and SHA1 Exynos: config: Enable ACE HW for SHA 256 for Exynos gen: Add sha h/w acceleration to hash Exynos: config: Enable hash command Exynos5: clock: Fix a typo bug in exynos clock init Exynos5: config: enable time command Exynos: pwm: Remove dead code of function exynos5_get_pwm_clk Albert ARIBAUD (13): Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master' Merge branch 'u-boot-ti/master' into 'u-boot-arm/master' Merge branch 'u-boot/master' into 'u-boot-arm/master' Merge branch 'u-boot-ti/master' into 'u-boot-arm/master' ARM: Fix __bss_start and __bss_end in linker scripts Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' ARM: fix CONFIG_SPL_MAX_SIZE semantics cam_enc_4xx: convert to CONFIG_SPL_MAX_FOOTPRINT da850evm, da850_am18xxevm: convert to CONFIG_SPL_MAX_FOOTPRINT smdk5250, snow: convert to CONFIG_SPL_MAX_FOOTPRINT cosmetic: fix CONFIG_SPL_BSS_MAX_SIZE typo in README Alexandre Pereira da Silva (1): mx23_olinuxino: Fix netboot console Andreas Bießmann (6): omap3/cpu.h: add BCH support asm/omap_gpmc.h: consolidate common defines omap3/omap_gpmc.h: add ooblayout for BCH8 as in kernel omap_gpmc: change nandecc command omap_gpmc: add support for hw assisted BCH8 tricorder: enable hw assisted BCH8 in SPL and u-boot Andrew Gabbasov (1): fsl_esdhc: Fix DMA transfer completion waiting loop Benoît Thébaudeau (29): mx25pdk: Enable imxdi RTC nand: mxc: Prepare to add support for i.MX5 nand: mxc: Add support for i.MX5 imx: mx5: lowlevel_init: Simplify code imx: mx53ard: Add support for NAND Flash nand: mxc: Fix debug trace in mxc_nand_read_oob_syndrome() nand: mxc: Use appropriate page number in syndrome functions arm: start.S: Fix _TEXT_BASE for SPL arm: relocate_code() is no longer noreturn arm1136: Remove redundant relocate_code() return arm: relocate_code(): Remove useless relocation offset computation arm: relocate_code(): Use __image_copy_end for end of relocation arm: crt0.S: Remove bogus .globl autoconfig.mk: Make it possible to define configs from other configs Makefile: Change CONFIG_SPL_PAD_TO to image offset imx: Fix automatic make targets for imx images nand: mxc: Switch NAND SPL to generic SPL arm926ejs: Remove deprecated and now unused NAND SPL arm: Remove unused relocate_code() parameters Makefile: Move SHELL setup to config.mk .gitignore: Add /SPL imx: Add u-boot-with-spl.imx make target imx: Add u-boot-with-nand-spl.imx make target arm: Remove support for smdk6400 Revert "mkconfig: start deprecating Makefile config targets" arm: Remove support for unused s3c64xx arm: Remove deprecated and now unused NAND SPL arm1176: Remove unused MMU setup from start.S arm: Make all linker scripts compatible with per-symbol sections Bin Liu (2): musb: am335x: disable bulk split-combine feature musb: set MUSB speed based on CONFIG Che-Liang Chiou (1): Exynos: Add timer_get_us function Dirk Behme (1): spi: mxc_spi: Fix ECSPI reset handling Eric Nelson (3): i.MX6: Add hdmidet command to detect attached HDMI monitor i.MX6: mx6qsabrelite: discard override of CONFIG_ARP_TIMEOUT fsl_esdhc: flush cache after IO completion Fabio Estevam (14): mxs: spl_mem_init: Align DDR2 init with FSL
Re: [U-Boot] [PATCH v3 4/8] arm: bootm: call udc_disable() before booting linux
Hi Mike, On Fri, 12 Apr 2013 11:59:16 -0700, Mike Dunn wrote: > On the pxa270, if the udc device is not disabled before jumping to linux, the > device fails to initialize in linux because it was left in a running state, > and > the linux driver assumes that it is in a disabled state. > > Signed-off-by: Mike Dunn > --- > Changelog: > v3: no change > v2: no change > > Arguably, this is a bug in the linux driver, but it seemed pretty simple and > benign to just disable it in u-boot. I'll also send a patch to upstream > kernel > to fix its driver. > > arch/arm/include/asm/bootm.h |1 + > arch/arm/lib/bootm.c |1 + > 2 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/include/asm/bootm.h b/arch/arm/include/asm/bootm.h > index db2ff94..68189cc 100644 > --- a/arch/arm/include/asm/bootm.h > +++ b/arch/arm/include/asm/bootm.h > @@ -21,6 +21,7 @@ > > #ifdef CONFIG_USB_DEVICE > extern void udc_disconnect(void); > +extern void udc_disable(void); > #endif > > #endif > diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c > index f3b30c5..6daa7bf 100644 > --- a/arch/arm/lib/bootm.c > +++ b/arch/arm/lib/bootm.c > @@ -105,6 +105,7 @@ static void announce_and_cleanup(void) > > #ifdef CONFIG_USB_DEVICE > udc_disconnect(); > + udc_disable(); > #endif > cleanup_before_linux(); > } Acked-By: 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 4/4] mx5: Add support for DENX M53EVK
Dear Wolfgang Denk, > Dear Marek Vasut, > > In message <201304141920.32212.ma...@denx.de> you wrote: > > > Just curious: which method did you use to flash the final binary into > > > the NAND? Did you boot the kernel and used mtd-utils? > > > > > > Maybe we could add such info later into a README? > > > > I just wrote the resulting u-boot.nand to the 0x0 of the NAND. > > This is not exactly a very precise instruction... Use simple "nand write" to flash the resulting image to address 0x0 of the nand, that's all. > How exactly do I write to NAND on a virgin (or bricked) system? > I think Fabio's request makes a lot of sense - yes, you know how to > do this, but I don't, and neither does the average user. This will change anyway, as will the rest of the patchset as I will need to rework it on top of Benoit's patches. > Can we > please document this? With sufficient detail everybody understands > which tools you used to do this, and what the exact steps where to > perform the operation? > > Thanks. > > Wolfgang Denk 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 4/4] mx5: Add support for DENX M53EVK
Dear Marek Vasut, In message <201304141920.32212.ma...@denx.de> you wrote: > > > Just curious: which method did you use to flash the final binary into the > > NAND? Did you boot the kernel and used mtd-utils? > > > > Maybe we could add such info later into a README? > > I just wrote the resulting u-boot.nand to the 0x0 of the NAND. This is not exactly a very precise instruction... How exactly do I write to NAND on a virgin (or bricked) system? I think Fabio's request makes a lot of sense - yes, you know how to do this, but I don't, and neither does the average user. Can we please document this? With sufficient detail everybody understands which tools you used to do this, and what the exact steps where to perform the operation? Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. - Fred Brooks, Jr. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/8] add support for palm treo 680 board
Dear Mike Dunn,
[...]
> +int board_init(void)
> +{
> + /* We have RAM, disable cache */
> + dcache_disable();
> + icache_disable();
> +
> + gd->bd->bi_arch_number = MACH_TYPE_TREO680;
This is not needed, just define CONFIG_MACH_TYPE in treo680.h
> + gd->bd->bi_boot_params = 0xa100;
Is this not CONFIG_SYS_DRAM_BASE + 0x100 ? I think it is.
> +
> + return 0;
> +}
> +
> +int dram_init(void)
> +{
> + /* IPL initializes SDRAM (we're already running from it) */
> + gd->ram_size = PHYS_SDRAM_1_SIZE;
> + return 0;
> +}
> +
> +#ifdef CONFIG_LCD
> +void lcd_enable(void)
> +{
> + /*
> + * Undo the L_BIAS / gpio77 pin configuration performed by the pxa lcd
> + * driver code. We need it as an output gpio.
> + */
> + writel((readl(GAFR2_L) & ~(0xc << 24)), GAFR2_L);
> +
> + /* power-up and enable the lcd */
> + writel(0x0040, GPSR(86)); /* enable; drive high */
> + writel(0x2000, GPSR(77)); /* power; drive high */
> + writel(0x0200, GPCR(25)); /* enable_n; drive low */
> +
> + /* turn on LCD backlight and configure PWM for reasonable brightness */
> + writel(0x00, PWM_CTRL0);
> + writel(0x1b1, PWM_PERVAL0);
> + writel(0xfd, PWM_PWDUTY0);
> + writel(0x0040, GPSR(38)); /* backlight power on */
> +}
> +#endif
> +
> +#ifdef CONFIG_MMC
> +int board_mmc_init(bd_t *bis)
> +{
> + writel(0x0400, GPSR(42)); /* power on */
Can you not use your bitlibrary for this stuff? Or maybe at least use (1 << n)
here to make it more readable.
But seriously, do you not want to (in the longer run) implement proper GPIO
driver for PXA? That'd help a lot. Also, do you not want to volunteer to fix
PXA? I think it's a bit rotting all around ;-)
> + return pxa_mmc_register(0);
> +}
> +#endif
> +
> +void board_nand_init(void)
> +{
> + /* we have one 128M diskonchip G4 */
> +
> + struct mtd_info *mtd = &nand_info[0];
> + struct nand_chip *nand = &docg4_nand_chip;
> + if (docg4_nand_init(mtd, nand, 0))
> + hang();
> +}
> +
> +#ifdef CONFIG_SPL_BUILD
> +void *memcpy(void *dest, const void *src, size_t count)
> +{
CONFIG_SPL_LIBCOMMON_SUPPORT shall give you memcpy.
[...]
> +void nand_boot(void)
> +{
[...]
Will the common/spl/ NAND loading code not cut it here? I guess it won't since
PXA is FUBAR when it comes to any kind of SPL loading. Do you not want to fix
that? I'd be really grateful if you did ;-)
[...]
btw. you dont really need to #define CONFIG_PXA27X to value "1" in your config,
just remove those useless trailing "1"s .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] usb: ss: Some fixes and cleanup for USB super-speed support
Dear Vivek Gautam, > Based on 'u-boot-usb' master branch. > > This patch-series includes majorly some clean-up, few fixes and > then some basic super-speed usb infrastructure addition, to help > put support for XHCI in near future. btw can you test your patches with MAKEALL -a arm? I get this: - SUMMARY Boards compiled: 306 Boards with errors: 65 ( qong mx35pdk gplugd at91sam9m10g45ek_nandflash pogo_e02 dns325 iconnect lschlv2 lsxhl d2net_v2 inetspace_v2 net2big_v2 netspace_lite_v2 netspace_max_v2 netspace_v2 wireless_space dreamplug guruplug mv88f6281gtw_ge openrd_base openrd_client openrd_ultimate rd6281a sheevaplug ib62x0 dockstar tk71 zmx25 mx23_olinuxino apx4devkit mx23evk m28evk mx28evk sc_sps_1 edminiv2 mx51_efikamx mx51_efikasb mx51evk mx53loco mx6qsabreauto mx6qsabrelite nitrogen6dl nitrogen6dl2g nitrogen6q nitrogen6q2g nitrogen6s nitrogen6s1g cm_t35 mt_ventoux omap3_beagle mcx twister omap4_panda snow smdk5250 harmony seaboard ventana whistler colibri_t20_iris plutux medcom-wide tec paz00 trimslice ) -- 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 8/8] palmtreo680: add utility that writes u-boot to flash
Dear Mike Dunn,
> This adds a userspace linux utility that writes the u-boot image to an mtd
> partition on the docg4 nand flash.
>
> A special utility is required to do this because u-boot is partially loaded
> by an initial program loader (IPL) that is permanently programmed to the
> boot region of the flash. This IPL expects the image to be written in a
> unique format. The characteristics of this format can be summarized as
> follows: - Flash blocks to be loaded must have a magic number in the oob
> bytes of the first page of the block.
> - Each page must be written redundantly in the subsequent page.
> - The integrated flash controller's "reliable mode" is used, requiring
> that alternate 2k regions (4 pages) are skipped when writing.
> For these reasons, a u-boot image can not be written using nandwrite from
> mtd-utils.
>
> Signed-off-by: Mike Dunn
> ---
> Changelog:
> v3: new patch; split off from patch 7 in v2 of patchset
>
> tools/palmtreo680/flash_u-boot.c | 167
> ++ 1 files changed, 167 insertions(+),
> 0 deletions(-)
> create mode 100644 tools/palmtreo680/flash_u-boot.c
>
> diff --git a/tools/palmtreo680/flash_u-boot.c
> b/tools/palmtreo680/flash_u-boot.c new file mode 100644
> index 000..97b336f
> --- /dev/null
> +++ b/tools/palmtreo680/flash_u-boot.c
> @@ -0,0 +1,167 @@
> +/*
> + * Copyright (C) 2013 Mike Dunn
> + *
> + * This file is released under the terms of GPL v2 and any later version.
> + * See the file COPYING in the root directory of the source tree for
> details. + *
> + *
> + * This is a userspace Linux utility that, when run on the Treo 680, will
> + * program u-boot to flash. The docg4 driver *must* be loaded with the
> + * reliable_mode and ignore_badblocks parameters enabled:
> + *
> + *modprobe docg4 ignore_badblocks=1 reliable_mode=1
> + *
> + * This utility writes the concatenated spl + u-boot image to the start of
> the + * mtd device in the format expected by the IPL/SPL. The image file
> and mtd + * device node are passed to the utility as arguments. The
> blocks must have + * been erased beforehand.
> + *
> + * When you compile this, note that it links to libmtd from mtd-utils, so
> ensure + * that your include and lib paths include this.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "libmtd.h"
> +
> +#define RELIABLE_BLOCKSIZE 0x1 /* block capacity in reliable mode */
> +#define STANDARD_BLOCKSIZE 0x4 /* block capacity in normal mode */
> +#define PAGESIZE 512
> +#define PAGES_PER_BLOCK 512
> +#define OOBSIZE 7/* available to user (16 total) */
> +
> +uint8_t ff_oob[OOBSIZE] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
> +
> +/* this is the magic number the IPL looks for (ASCII "BIPO") */
> +uint8_t page0_oob[OOBSIZE] = {'B', 'I', 'P', 'O', 0xff, 0xff, 0xff};
> +
> +int main(int argc, char * const argv[])
> +{
> + int devfd, datafd, num_blocks, block;
> + off_t file_size;
> + libmtd_t mtd_desc;
> + struct mtd_dev_info devinfo;
> + uint8_t *blockbuf;
> + char response[8];
> +
> + if (argc != 3) {
> + printf("usage: %s \n", argv[0]);
> + exit(-1);
Use proper errno and "return" as you're returning from main() anyway.
> + }
> +
> + mtd_desc = libmtd_open();
> + if (mtd_desc == NULL) {
> + fprintf(stderr, "can't initialize libmtd\n");
> + exit(-1);
> + }
> +
> + /* open the spl image file and mtd device */
> + datafd = open(argv[1], O_RDONLY);
> + if (datafd == -1) {
> + perror(argv[1]);
> + exit(-1);
> + }
> + devfd = open(argv[2], O_WRONLY);
> + if (devfd == -1) {
> + perror(argv[2]);
> + exit(-1);
> + }
> + if (mtd_get_dev_info(mtd_desc, argv[2], &devinfo) < 0) {
> + fprintf(stderr, "mtd_get_dev_info failed\n");
> + exit(-1);
> + }
> +
> + /* determine the number of blocks needed by the image */
> + file_size = lseek(datafd, 0, SEEK_END);
> + if (file_size == (off_t)-1) {
> + perror("lseek");
> + exit(-1);
> + }
> + num_blocks = (file_size + RELIABLE_BLOCKSIZE - 1) / RELIABLE_BLOCKSIZE;
> + file_size = lseek(datafd, 0, SEEK_SET);
> + if (file_size == (off_t)-1) {
> + perror("lseek");
> + exit(-1);
> + }
> + printf("The mtd partition contains %d blocks\n", devinfo.eb_cnt);
> + printf("U-boot will occupy %d blocks\n", num_blocks);
> + if (num_blocks > devinfo.eb_cnt) {
> + fprintf(stderr, "Insufficient blocks on partition\n");
> + exit(-1);
> + }
> +
> + printf("IMPORTANT: These blocks must be in an erased state!\n");
> + printf("Do you want to proceed?\n");
> + scanf("%s", response);
> + if ((response[0] != 'y') && (response[0] != 'Y')) {
> + pri
Re: [U-Boot] [PATCH v3 4/8] arm: bootm: call udc_disable() before booting linux
Dear Mike Dunn, > On the pxa270, if the udc device is not disabled before jumping to linux, > the device fails to initialize in linux because it was left in a running > state, and the linux driver assumes that it is in a disabled state. > > Signed-off-by: Mike Dunn Albert, can I get your ACK on this? 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 v2 0/7] palm treo 680 smartphone board support
Hi Mike, > Hi, > > This patchset adds support for the Palm Treo 680 smartphone. I had to make > some minor tweaks to u-boot to get things working. Most of these changes > are small, and most only touch the pxa arch. > > Thanks for looking. I pushed what I considered ok to u-boot-pxa/master, please start your reworks on top of that. Thanks! 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 8/8] usb: common: Use a global macro for 'min3'
Dear Vivek Gautam,
> We can use a common global macro for calculating minimum of
> 3 numbers. Put the same in 'common header' and let 'ehci'
> use it.
>
> Signed-off-by: Vivek Gautam
> ---
>
> This patch added in V3(current-version) of this patch-series.
>
> drivers/usb/host/ehci-hcd.c | 10 --
> include/common.h|2 ++
> 2 files changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index c816878..bcecae3 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -587,16 +587,6 @@ fail:
> return -1;
> }
>
> -static inline int min3(int a, int b, int c)
> -{
> -
> - if (b < a)
> - a = b;
> - if (c < a)
> - a = c;
> - return a;
> -}
> -
> int
> ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer,
>int length, struct devrequest *req)
> diff --git a/include/common.h b/include/common.h
> index d41aeb4..37269c7 100644
> --- a/include/common.h
> +++ b/include/common.h
> @@ -211,6 +211,8 @@ typedef void (interrupt_handler_t)(void *);
> #define MIN(x, y) min(x, y)
> #define MAX(x, y) max(x, y)
>
> +#define min3(a, b, c)min(min(a, b), c)
> +
You might want to keep it as an inline-function to allow GCC do the type-
checking?
> /*
> * Return the absolute value of a number.
> *
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 5/7] usb: hub: Increase device enumeration timeout for broken drives
Dear Vivek Gautam, > Hi Marek, > > On Thu, Apr 4, 2013 at 9:28 AM, Marek Vasut wrote: > > Dear Vivek Gautam, > > > >> Hi Marek, > >> > >> On Thu, Mar 28, 2013 at 8:02 PM, Marek Vasut wrote: > >> > Dear Vivek Gautam, > >> > > >> >> Few broken usb mass storage devices can take some time to set > >> >> Current Connect Status (CCS) and Connect Status Change (CSC) in > >> >> Port status register after an attach. > >> >> So increasing some timeout when both CCS and CSC bits are not set. > >> >> > >> >> Signed-off-by: Amar > >> >> Signed-off-by: Vivek Gautam > >> > > >> > Can we not postpone checking of these CCS and CSC bits for such broken > >> > devices? This'd at least allow the "good" devices to be detected > >> > quickly and while these are handled, this would give some time for > >> > the "bad" ones to do their job too. > >> > >> We are thinking of one approach here. > >> Iterating over all the ports once, so that we find 'good' ports and > >> 'bad' ports By 'bad' port we mean that either the device connected to > >> it is bad or nothing is connected > >> to this port. > >> Once we are done with "usb_hub_port_connect_change()" and other jobs > >> for 'good' ports, > >> we iterate once again on bad ports. > >> Not sure how good this approach :-(. Any suggestions ? > > > > That might just work, but I wonder if it's worth it. It's a pity we can't > > make a list of those as they're not even probed yet :( > > True, but at this point of time atleast the CSC and CCS bits tell us > about whether something is connected or not. Right ? > So lets make the ports on which nothing is connected 'bad' and probe > them later so that if something is connected to these, > job can be done. > > If you are fine i may drop this patch from this series for now and > come back with a solution. > By the time i can update the patch-series. Sorry for the late reply again. I think the best way around here would be to make the delay configurable, possibly as an argument to "usb reset" with some reasonable default value, what do you think? 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 0/8] usb: ss: Some fixes and cleanup for USB super-speed support
Dear Vivek Gautam, > Based on 'u-boot-usb' master branch. > > This patch-series includes majorly some clean-up, few fixes and > then some basic super-speed usb infrastructure addition, to help > put support for XHCI in near future. > > Changes from v2: > - Added a patch "usb: common: Weed out USB_**_PRINTFs from usb framework" >to replace USB_***_PRINTF with debug() so as to get rid of unnecessary >DEBUG macros in usb common framework and thereby rebasing other patches >on top of this so that no USB_PRINTF appears further. > - Added a patch to reset only USB 2.0 ports, since USB 3.0 protocol ports >don't require a reset to happen to move to 'enabled' state. > - Added a patch to move definition of 'min3()' out of ehci-hcd and putting >the same as macro definition in common header. > - Using a 'switch-case' in portspeed() in cmd_usb.c > > Changes from v1: > - Fixing the issue with 'ifno' as well as added 'if_desc'. > - Instead of turning-on only powered-off hub ports, power-cycle all >the hub ports (aka: turning off and then turning on again power to >all the ports. > - Fixing commenting style problem in >'usb: Update device class in usb device's descriptor' > - Fixing typo in commit message for >'usb: hub: Fix enumration timeout' > - Removing separate definition for 'struct usb_ep_desc'; thereby adding >'struct usb_ss_ep_comp_descriptor' to 'struct usb_interface' only. >As a result modifying the patch accordingly also dropping the patch >'usb: eth: Fix for updated usb interface descriptor structure' > - Dropping the patch 'usb: hub: Increase device enumeration timeout for > broken drives' for now (will come back with a solution at later point of > time). Applied all but the last one, let's now base all subsequent patches on u-boot- usb/next please. 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 4/4] mx5: Add support for DENX M53EVK
Dear Fabio Estevam, > Hi Marek, > > On Mon, Feb 25, 2013 at 3:24 PM, Marek Vasut wrote: > > +/* > > + * Boot Device : one of > > + * spi, sd, nand > > + */ > > +BOOT_FROM nand > > Just curious: which method did you use to flash the final binary into the > NAND? Did you boot the kernel and used mtd-utils? > > Maybe we could add such info later into a README? I just wrote the resulting u-boot.nand to the 0x0 of the NAND. 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] cosmetic: fix CONFIG_SPL_BSS_MAX_SIZE typo in README
On Sun, 14 Apr 2013 16:48:38 +0200, Albert ARIBAUD wrote: > > Signed-off-by: Albert ARIBAUD > --- > README |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/README b/README > index 19da9c8..0bc0af5 100644 > --- a/README > +++ b/README > @@ -2835,7 +2835,7 @@ FIT uImage format: > Maximum size in memory allocated to the SPL, BSS included. > When defined, the linker checks that the actual memory > used by SPL from _start to __bss_end does not exceed it. > - CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_MAX_BSS_SIZE > + CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_BSS_MAX_SIZE > must not be both defined at the same time. > > CONFIG_SPL_MAX_SIZE > @@ -2858,7 +2858,7 @@ FIT uImage format: > Maximum size in memory allocated to the SPL BSS. > When defined, the linker checks that the actual memory used > by SPL from __bss_start to __bss_end does not exceed it. > - CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_MAX_BSS_SIZE > + CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_BSS_MAX_SIZE > must not be both defined at the same time. > > CONFIG_SPL_STACK Applied to u-boot-arm/master. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cosmetic: fix CONFIG_SPL_BSS_MAX_SIZE typo in README
Hi Albert, On Sunday, April 14, 2013 4:51:26 PM, Albert ARIBAUD wrote: > Hi Albert, > > On Sun, 14 Apr 2013 16:48:38 +0200, Albert ARIBAUD > wrote: > > > > > Signed-off-by: Albert ARIBAUD > > --- > > README |4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/README b/README > > index 19da9c8..0bc0af5 100644 > > --- a/README > > +++ b/README > > @@ -2835,7 +2835,7 @@ FIT uImage format: > > Maximum size in memory allocated to the SPL, BSS included. > > When defined, the linker checks that the actual memory > > used by SPL from _start to __bss_end does not exceed it. > > - CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_MAX_BSS_SIZE > > + CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_BSS_MAX_SIZE > > must not be both defined at the same time. > > > > CONFIG_SPL_MAX_SIZE > > @@ -2858,7 +2858,7 @@ FIT uImage format: > > Maximum size in memory allocated to the SPL BSS. > > When defined, the linker checks that the actual memory used > > by SPL from __bss_start to __bss_end does not exceed it. > > - CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_MAX_BSS_SIZE > > + CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_BSS_MAX_SIZE > > must not be both defined at the same time. > > > > CONFIG_SPL_STACK > > Benoît, is this OK? If so, I'll apply it on ARM. It is. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cosmetic: fix CONFIG_SPL_BSS_MAX_SIZE typo in README
Hi Albert, On Sun, 14 Apr 2013 16:48:38 +0200, Albert ARIBAUD wrote: > > Signed-off-by: Albert ARIBAUD > --- > README |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/README b/README > index 19da9c8..0bc0af5 100644 > --- a/README > +++ b/README > @@ -2835,7 +2835,7 @@ FIT uImage format: > Maximum size in memory allocated to the SPL, BSS included. > When defined, the linker checks that the actual memory > used by SPL from _start to __bss_end does not exceed it. > - CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_MAX_BSS_SIZE > + CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_BSS_MAX_SIZE > must not be both defined at the same time. > > CONFIG_SPL_MAX_SIZE > @@ -2858,7 +2858,7 @@ FIT uImage format: > Maximum size in memory allocated to the SPL BSS. > When defined, the linker checks that the actual memory used > by SPL from __bss_start to __bss_end does not exceed it. > - CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_MAX_BSS_SIZE > + CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_BSS_MAX_SIZE > must not be both defined at the same time. > > CONFIG_SPL_STACK Benoît, is this OK? If so, I'll apply it on ARM. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cosmetic: fix CONFIG_SPL_BSS_MAX_SIZE typo in README
Signed-off-by: Albert ARIBAUD --- README |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README b/README index 19da9c8..0bc0af5 100644 --- a/README +++ b/README @@ -2835,7 +2835,7 @@ FIT uImage format: Maximum size in memory allocated to the SPL, BSS included. When defined, the linker checks that the actual memory used by SPL from _start to __bss_end does not exceed it. - CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_MAX_BSS_SIZE + CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_BSS_MAX_SIZE must not be both defined at the same time. CONFIG_SPL_MAX_SIZE @@ -2858,7 +2858,7 @@ FIT uImage format: Maximum size in memory allocated to the SPL BSS. When defined, the linker checks that the actual memory used by SPL from __bss_start to __bss_end does not exceed it. - CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_MAX_BSS_SIZE + CONFIG_SPL_MAX_FOOTPRINT and CONFIG_SPL_BSS_MAX_SIZE must not be both defined at the same time. CONFIG_SPL_STACK -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] Homogeneize semantics of CONFIG_SPL_MAX_SIZE
Hi Benoît, > > Applied to u-boot-arm/master, with README corrected on the fly as > > suggested by Tom. > > This on-the-fly correction is incomplete: > CONFIG_SPL_MAX_BSS_SIZE -> CONFIG_SPL_BSS_MAX_SIZE > > Best regards, > Benoît Argh! Where were you when I was typing? :) Well, since it is in the README, i.e. non-functional, there's no point in rolling back; I'll make it a cosmetic patch. Thanks for noticing it! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] Homogeneize semantics of CONFIG_SPL_MAX_SIZE
Hi Albert, On Sunday, April 14, 2013 4:10:37 PM, Albert ARIBAUD wrote: > On Fri, 12 Apr 2013 17:14:29 +0200, Albert ARIBAUD > wrote: > > > CONFIG_SPL_MAX_SIZE and CONFIG_SPL_BSS_MAX_SIZE did not have constant > > semantics across all of U-boot. This patch series aims at fixing this by > > splitting the maximum size into separate image (code + data + rodata + > > linker list) size on the one hand, and BSS size on the other hand. > > > > Changes in v4: > > - reordered patches so that FOOTPRINT is introduced first, > > then individual boards are switched to using it > > - rewrote README entries > > - converted to CONFIG_SPL_MAX_FOOTPRINT > > - limited SPL size to exactly 6 2K pages > > - converted to CONFIG_SPL_MAX_FOOTPRINT > > - converted to CONFIG_SPL_MAX_FOOTPRINT > > > > Changes in v3: > > - introduced CONFIG_SPL_MAX_FOOTPRINT > > - fixed typo in BSS size test > > > > Changes in v2: > > - removed mmutable in SPL linker file > > - brought back total size to 12K > > - fixed commit summary typoes > > - fixed spacing in commit summary > > > > Albert ARIBAUD (4): > > ARM: fix CONFIG_SPL_MAX_SIZE semantics > > cam_enc_4xx: convert to CONFIG_SPL_MAX_FOOTPRINT > > da850evm, da850_am18xxevm: convert to CONFIG_SPL_MAX_FOOTPRINT > > smdk5250, snow: convert to CONFIG_SPL_MAX_FOOTPRINT > > > > README | 18 -- > > arch/arm/cpu/u-boot-spl.lds| 24 > > +--- > > arch/arm/cpu/u-boot.lds|4 > > board/ait/cam_enc_4xx/u-boot-spl.lds |2 +- > > board/davinci/da8xxevm/u-boot-spl-da850evm.lds |2 +- > > board/samsung/smdk5250/smdk5250-uboot-spl.lds |2 +- > > include/configs/cam_enc_4xx.h |2 +- > > include/configs/da850evm.h |2 +- > > include/configs/exynos5250-dt.h|2 +- > > include/configs/tegra-common.h |2 +- > > 10 files changed, 36 insertions(+), 24 deletions(-) > > > > Applied to u-boot-arm/master, with README corrected on the fly as > suggested by Tom. This on-the-fly correction is incomplete: CONFIG_SPL_MAX_BSS_SIZE -> CONFIG_SPL_BSS_MAX_SIZE Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] Homogeneize semantics of CONFIG_SPL_MAX_SIZE
On Fri, 12 Apr 2013 17:14:29 +0200, Albert ARIBAUD wrote: > CONFIG_SPL_MAX_SIZE and CONFIG_SPL_BSS_MAX_SIZE did not have constant > semantics across all of U-boot. This patch series aims at fixing this by > splitting the maximum size into separate image (code + data + rodata + > linker list) size on the one hand, and BSS size on the other hand. > > Changes in v4: > - reordered patches so that FOOTPRINT is introduced first, > then individual boards are switched to using it > - rewrote README entries > - converted to CONFIG_SPL_MAX_FOOTPRINT > - limited SPL size to exactly 6 2K pages > - converted to CONFIG_SPL_MAX_FOOTPRINT > - converted to CONFIG_SPL_MAX_FOOTPRINT > > Changes in v3: > - introduced CONFIG_SPL_MAX_FOOTPRINT > - fixed typo in BSS size test > > Changes in v2: > - removed mmutable in SPL linker file > - brought back total size to 12K > - fixed commit summary typoes > - fixed spacing in commit summary > > Albert ARIBAUD (4): > ARM: fix CONFIG_SPL_MAX_SIZE semantics > cam_enc_4xx: convert to CONFIG_SPL_MAX_FOOTPRINT > da850evm, da850_am18xxevm: convert to CONFIG_SPL_MAX_FOOTPRINT > smdk5250, snow: convert to CONFIG_SPL_MAX_FOOTPRINT > > README | 18 -- > arch/arm/cpu/u-boot-spl.lds| 24 > +--- > arch/arm/cpu/u-boot.lds|4 > board/ait/cam_enc_4xx/u-boot-spl.lds |2 +- > board/davinci/da8xxevm/u-boot-spl-da850evm.lds |2 +- > board/samsung/smdk5250/smdk5250-uboot-spl.lds |2 +- > include/configs/cam_enc_4xx.h |2 +- > include/configs/da850evm.h |2 +- > include/configs/exynos5250-dt.h|2 +- > include/configs/tegra-common.h |2 +- > 10 files changed, 36 insertions(+), 24 deletions(-) > Applied to u-boot-arm/master, with README corrected on the fly as suggested by Tom. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] : Please pull u-boot-imx
Hi Stefano, On Sun, 14 Apr 2013 11:34:29 +0200, Stefano Babic wrote: > Sorry Albert, > > there are two more fixes that I have not merged before. Please pull from > u-boot-imx again, thanks. > > The following changes since commit 0f1411bc8dade4472ca802f46f75714e67301bb0: > > spi: mxc_spi: Set master mode for all channels (2013-04-13 17:46:42 +0200) > > are available in the git repository at: > > git://www.denx.de/git/u-boot-imx.git master > > for you to fetch changes up to 9b74dc56fba2b9db39420f81c990284f36d5801f: > > fsl_esdhc: Fix DMA transfer completion waiting loop (2013-04-14 > 11:22:47 +0200) > > > Andrew Gabbasov (1): > fsl_esdhc: Fix DMA transfer completion waiting loop > > Eric Nelson (1): > fsl_esdhc: flush cache after IO completion > > drivers/mmc/fsl_esdhc.c |8 +++- > include/fsl_esdhc.h |4 +++- > 2 files changed, 6 insertions(+), 6 deletions(-) > Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] : Please pull u-boot-imx
Sorry Albert, there are two more fixes that I have not merged before. Please pull from u-boot-imx again, thanks. The following changes since commit 0f1411bc8dade4472ca802f46f75714e67301bb0: spi: mxc_spi: Set master mode for all channels (2013-04-13 17:46:42 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to 9b74dc56fba2b9db39420f81c990284f36d5801f: fsl_esdhc: Fix DMA transfer completion waiting loop (2013-04-14 11:22:47 +0200) Andrew Gabbasov (1): fsl_esdhc: Fix DMA transfer completion waiting loop Eric Nelson (1): fsl_esdhc: flush cache after IO completion drivers/mmc/fsl_esdhc.c |8 +++- include/fsl_esdhc.h |4 +++- 2 files changed, 6 insertions(+), 6 deletions(-) -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] fsl_esdhc: Fix DMA transfer completion waiting loop
On 14/04/2013 09:19, Dirk Behme wrote: > Am 08.04.2013 11:06, schrieb Andrew Gabbasov: >> Rework the waiting for transfer completion loop condition >> to continue waiting until both Transfer Complete and DMA End >> interrupts occur. Checking of DLA bit in Present State register >> looks not needed in addition to interrupts status checking, >> so it can be removed from the condition. Also, DMA Error >> condition is added to the list of data errors, checked in the loop. >> >> Signed-off-by: Andrew Gabbasov >> --- >> drivers/mmc/fsl_esdhc.c |3 +-- >> include/fsl_esdhc.h |4 +++- >> 2 files changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c >> index 54b5363..814bba4 100644 >> --- a/drivers/mmc/fsl_esdhc.c >> +++ b/drivers/mmc/fsl_esdhc.c >> @@ -400,8 +400,7 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd >> *cmd, struct mmc_data *data) >> >> if (irqstat & DATA_ERR) >> return COMM_ERR; >> -} while (!(irqstat & IRQSTAT_TC) && >> -(esdhc_read32(®s->prsstat) & PRSSTAT_DLA)); >> +} while ((irqstat & DATA_COMPLETE) != DATA_COMPLETE); >> #endif >> } >> >> diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h >> index 47d2fe4..ea0880b 100644 >> --- a/include/fsl_esdhc.h >> +++ b/include/fsl_esdhc.h >> @@ -63,7 +63,9 @@ >> #define IRQSTAT_CC(0x0001) >> >> #define CMD_ERR(IRQSTAT_CIE | IRQSTAT_CEBE | IRQSTAT_CCE) >> -#define DATA_ERR(IRQSTAT_DEBE | IRQSTAT_DCE | IRQSTAT_DTOE) >> +#define DATA_ERR(IRQSTAT_DEBE | IRQSTAT_DCE | IRQSTAT_DTOE | \ >> +IRQSTAT_DMAE) >> +#define DATA_COMPLETE(IRQSTAT_TC | IRQSTAT_DINT) >> >> #define IRQSTATEN0x0002e034 >> #define IRQSTATEN_DMAE(0x1000) > > I can't say anything to the content of the patches ;) > > But are this patch and the patch from Eric > > http://patchwork.ozlabs.org/patch/233595/ > > fine and should be applied together, now? I see the same. I apply both on u-boot-imx and send an update pull request to Albert. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] : Please pull u-boot-imx
Hi Stefano,
On Sun, 14 Apr 2013 09:27:34 +0200, Stefano Babic
wrote:
> Hallo Albert,
>
> I have a couple of fixes for the release. Please pull from u-boot-imx,
> thanks !
>
> The following changes since commit d36b39bf0d1dbe4ef03f7fc1f20b2e52eb90acf5:
>
> spi: mxc_spi: Fix ECSPI reset handling (2013-04-04 10:23:09 +0200)
>
> are available in the git repository at:
>
> git://www.denx.de/git/u-boot-imx.git master
>
> for you to fetch changes up to 0f1411bc8dade4472ca802f46f75714e67301bb0:
>
> spi: mxc_spi: Set master mode for all channels (2013-04-13 17:46:42 +0200)
>
>
> Fabio Estevam (1):
> spi: mxc_spi: Set master mode for all channels
>
> Otavio Salvador (1):
> mx6qsabre{sd, auto}: Fix environment as 'mmc rescan' takes no
> arguments
>
> arch/arm/include/asm/arch-mx5/imx-regs.h |1 +
> arch/arm/include/asm/arch-mx6/imx-regs.h |1 +
> drivers/spi/mxc_spi.c| 17 +
> include/configs/mx6qsabre_common.h |2 +-
> 4 files changed, 12 insertions(+), 9 deletions(-)
>
>
Applied to u-boot-arm/master, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Provide more useful debugging when an initcall fails
Dear Simon Glass, In message <1365863234-22906-1-git-send-email-...@chromium.org> you wrote: > The debug() which prints out the current call is not very useful, since if > it is called early enough (such as before the console is ready in the > pre-relocation board_init_f() sequence) it can hang the board. This should not happen (and if it does, that wouldbe a bug that needs fixing). > It is more useful to print a message when a call fails, and in this case > the non-relocated symbol address provides a way for the offending function > to be located in System.map. No. it is a long styanding rule that for this tyoe of actions the begin of the message gets printed before even attempting to call the respective function, so if the systemn hangs you can see the last operation which was about to be run. I think we should follow this principle here, too. 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 "Love is an ideal thing, marriage a real thing; a confusion of the real with the ideal never goes unpunished." - Goethe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] : Please pull u-boot-imx
Hallo Albert,
I have a couple of fixes for the release. Please pull from u-boot-imx,
thanks !
The following changes since commit d36b39bf0d1dbe4ef03f7fc1f20b2e52eb90acf5:
spi: mxc_spi: Fix ECSPI reset handling (2013-04-04 10:23:09 +0200)
are available in the git repository at:
git://www.denx.de/git/u-boot-imx.git master
for you to fetch changes up to 0f1411bc8dade4472ca802f46f75714e67301bb0:
spi: mxc_spi: Set master mode for all channels (2013-04-13 17:46:42 +0200)
Fabio Estevam (1):
spi: mxc_spi: Set master mode for all channels
Otavio Salvador (1):
mx6qsabre{sd, auto}: Fix environment as 'mmc rescan' takes no
arguments
arch/arm/include/asm/arch-mx5/imx-regs.h |1 +
arch/arm/include/asm/arch-mx6/imx-regs.h |1 +
drivers/spi/mxc_spi.c| 17 +
include/configs/mx6qsabre_common.h |2 +-
4 files changed, 12 insertions(+), 9 deletions(-)
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch] fsl_esdhc: Fix DMA transfer completion waiting loop
Am 08.04.2013 11:06, schrieb Andrew Gabbasov: Rework the waiting for transfer completion loop condition to continue waiting until both Transfer Complete and DMA End interrupts occur. Checking of DLA bit in Present State register looks not needed in addition to interrupts status checking, so it can be removed from the condition. Also, DMA Error condition is added to the list of data errors, checked in the loop. Signed-off-by: Andrew Gabbasov --- drivers/mmc/fsl_esdhc.c |3 +-- include/fsl_esdhc.h |4 +++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index 54b5363..814bba4 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -400,8 +400,7 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data) if (irqstat & DATA_ERR) return COMM_ERR; - } while (!(irqstat & IRQSTAT_TC) && - (esdhc_read32(®s->prsstat) & PRSSTAT_DLA)); + } while ((irqstat & DATA_COMPLETE) != DATA_COMPLETE); #endif } diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h index 47d2fe4..ea0880b 100644 --- a/include/fsl_esdhc.h +++ b/include/fsl_esdhc.h @@ -63,7 +63,9 @@ #define IRQSTAT_CC(0x0001) #define CMD_ERR (IRQSTAT_CIE | IRQSTAT_CEBE | IRQSTAT_CCE) -#define DATA_ERR (IRQSTAT_DEBE | IRQSTAT_DCE | IRQSTAT_DTOE) +#define DATA_ERR (IRQSTAT_DEBE | IRQSTAT_DCE | IRQSTAT_DTOE | \ + IRQSTAT_DMAE) +#define DATA_COMPLETE (IRQSTAT_TC | IRQSTAT_DINT) #define IRQSTATEN 0x0002e034 #define IRQSTATEN_DMAE(0x1000) I can't say anything to the content of the patches ;) But are this patch and the patch from Eric http://patchwork.ozlabs.org/patch/233595/ fine and should be applied together, now? Thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: mxc_spi: Set master mode for all channels
Am 10.04.2013 01:06, schrieb Fabio Estevam:
From: Fabio Estevam
The glitch in the SPI clock line, which commit 3cea335c34 (spi: mxc_spi: Fix spi
clock glitch durant reset) solved, is back now and itwas re-introduced by
commit d36b39bf0d (spi: mxc_spi: Fix ECSPI reset handling).
Actually the glitch is happening due to always toggling between slave mode
and master mode by configuring the CHANNEL_MODE bits in this reset function.
Since the spi driver only supports master mode, set the mode for all channels
always to master mode in order to have a stable, "glitch-free" SPI clock line.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Introduce MXC_CSPICTRL_MODE_MASK definition
- Remove additional read of reg_ctrl
arch/arm/include/asm/arch-mx5/imx-regs.h |1 +
arch/arm/include/asm/arch-mx6/imx-regs.h |1 +
drivers/spi/mxc_spi.c| 17 +
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 249d15a..a71cc13 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -230,6 +230,7 @@
#define MXC_CSPICTRL_EN (1 << 0)
#define MXC_CSPICTRL_MODE (1 << 1)
#define MXC_CSPICTRL_XCH (1 << 2)
+#define MXC_CSPICTRL_MODE_MASK (0xf << 4)
#define MXC_CSPICTRL_CHIPSELECT(x)(((x) & 0x3) << 12)
#define MXC_CSPICTRL_BITCOUNT(x) (((x) & 0xfff) << 20)
#define MXC_CSPICTRL_PREDIV(x)(((x) & 0xF) << 12)
diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
b/arch/arm/include/asm/arch-mx6/imx-regs.h
index eaa7439..d79ab2f 100644
--- a/arch/arm/include/asm/arch-mx6/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
@@ -346,6 +346,7 @@ struct cspi_regs {
#define MXC_CSPICTRL_EN (1 << 0)
#define MXC_CSPICTRL_MODE (1 << 1)
#define MXC_CSPICTRL_XCH (1 << 2)
+#define MXC_CSPICTRL_MODE_MASK (0xf << 4)
#define MXC_CSPICTRL_CHIPSELECT(x)(((x) & 0x3) << 12)
#define MXC_CSPICTRL_BITCOUNT(x) (((x) & 0xfff) << 20)
#define MXC_CSPICTRL_PREDIV(x)(((x) & 0xF) << 12)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 4c19e0b..20419e6 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -137,11 +137,15 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs,
unsigned int cs,
return -1;
}
- /* Reset spi */
- reg_write(®s->ctrl, 0);
- reg_write(®s->ctrl, MXC_CSPICTRL_EN);
-
- reg_ctrl = reg_read(®s->ctrl);
+ /*
+* Reset SPI and set all CSs to master mode, if toggling
+* between slave and master mode we might see a glitch
+* on the clock line
+*/
+ reg_ctrl = MXC_CSPICTRL_MODE_MASK;
I was offline some days, giving me some time to think about this ;)
Most probably it does no harm, but I somehow feel uncomfortable with
setting *all* CSs to master mode. Just because there might be already
(one, several?) CS at master mode and switching it back to the (reset
default) slave will give a glitch on the clock line.
Wouldn't it be cleaner to keep the master mode only for the CS which
are already in master mode before?
E.g. instead of
reg_ctrl = MXC_CSPICTRL_MODE_MASK;
from above something like
reg_ctrl = reg_read(®s->ctrl) & MXC_CSPICTRL_MODE_MASK;
?
And then ...
+ reg_write(®s->ctrl, reg_ctrl);
+ reg_ctrl |= MXC_CSPICTRL_EN;
+ reg_write(®s->ctrl, reg_ctrl);
/*
* The following computation is taken directly from Freescale's code.
@@ -174,9 +178,6 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, unsigned
int cs,
reg_ctrl = (reg_ctrl & ~MXC_CSPICTRL_POSTDIV(0x0F)) |
MXC_CSPICTRL_POSTDIV(post_div);
- /* always set to master mode */
- reg_ctrl |= 1 << (cs + 4);
... keeping thins line?
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
