[U-Boot] dm3730: dpll5 init broken with 19.2MHz?

Hi, I have a custom OMAP37xx board running with a fairly uncommon 19.2MHz oscillator. The general clock setup seems fine so far, but the dpll5_init_34xx() used in prcm_init() for 36xx cpu-types gives me trouble in the form of numerous stack dumps in the kernel boot. Reason is: [3.396636]

[U-Boot] [PATCH] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.

ch, kernel panics disappear and USB working fine in u-boot and kernel. Signed-off-by: Andreas Naumann --- arch/arm/cpu/armv7/omap3/clock.c | 20 +++- arch/arm/cpu/armv7/omap3/lowlevel_init.S | 18 ++ arch/arm/include/asm/arch-omap3/clocks_om

[U-Boot] [RFC] ARM: omap3: Add option to disable errata workarounds.

Hi, It seems that all three ARM errata workarounds done in omap3 board-init (#454179 #430973 #621766) are solved/not longer needed e.g. in the AM/DM37xx chips. Other people have noticed this: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/254742.aspx When still applying them (especcially #4

Re: [U-Boot] [RFC] ARM: omap3: Add option to disable errata workarounds.

Hi, It seems that all three ARM errata workarounds done in omap3 board-init (#454179 #430973 #621766) are solved/not longer needed e.g. in the AM/DM37xx chips. Other people have noticed this: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/254742.aspx When still applying them (especcially #430

[U-Boot] fatload from eMMC general purpose partition

Hi, using an eMMC I want to load uImage and dtb from a general purpose partition (since these can be configured as pSLC independent of the user data area). From the kernel I can format and access the GP-partition, in my case mkfs.vfat. However, U-Boots fatload/extload on the GP-partition do no

Re: [U-Boot] fatload from eMMC general purpose partition

Hi, Could you share exact output from your console? below follows some linux console output from writing some file to a gp- and a user data partion (foo/bar). After that trying to see that file from U-Boot...: [root]# ls /dev/mmcblk3* /dev/mmcblk3 /dev/mmcblk3boot1 /dev/mmcblk3gp0p1 /

Re: [U-Boot] [PATCH V2] arm: omap: i2c: don't zero cnt in i2c_write

Hi, Am 28.11.2013 17:04, schrieb Nikita Kiryanov: Writing zero into I2Ci.I2C_CNT register causes random I2C failures in OMAP3 based devices. This seems to be related to the following advisory which apears in multiple erratas for OMAP3 SoCs (OMAP35xx, DM37xx), as well as OMAP4430 TRM: Advisory:

Re: [U-Boot] am3517: segmentation fault in Linux after upgrading from arago src to mainline u-boot

Hi Tom, Am 29.11.2013 12:09, schrieb Yegor Yefremov: On Thu, Nov 28, 2013 at 5:57 PM, Tom Rini wrote: On Thu, Nov 28, 2013 at 05:39:09PM +0100, Yegor Yefremov wrote: I'm having problems with the new u-boot (November 2013) and am3517 SoC. When I start Debian 7.0 armhf I get lots of Segmentat

Re: [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.

With this patch, kernel panics disappear and USB working fine in u-boot and kernel. Signed-off-by: Andreas Naumann While this patch works with Linux that has been patched for this erratum, it will cause problems with some unpatched versions of Linux. Right. So Linux also needs to be patch

Re: [U-Boot] ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e.

Hi Roger, What are the symptoms you see when this issue triggers? The symptoms are erroneous USB transaction, seen with a USB port analyzer. These only sometimes (not always) stall the USB communication, e.g. a USB mass storage device cant be read any longer. What is the test case to tr