Re: [U-Boot] [PATCH 0/4] Tegra210 support for P2571
Hi Tom, I've got one of these shield things - it is a seriously cool piece of hardware. I've have to read a bit about what is it for. So, any idea where to find a UART and recovery button? Regards, Simon On 17 June 2015 at 16:44, Tom Warren twar...@nvidia.com wrote: Yes, it's a 32-bit T210 U-Boot. T210 supports both AARCH32 and AARCH64. A 64-bit build will follow, but I haven't figured out how to meld the 32-bit AVP SPL portion/build with the 64-bit CPU portion/build in one clean build command, so I'm building them separately and then fusing them together in a separate script. If anyone has ideas on how to generate a hybrid 32-bit (AVP)/64-bit (A57) U-Boot binary in one fell swoop, I'm all ears. :) Tom -Original Message- From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Wednesday, June 17, 2015 1:07 PM To: Tom Warren Cc: u-boot@lists.denx.de; Stephen Warren; Tom Warren Subject: Re: [U-Boot] [PATCH 0/4] Tegra210 support for P2571 On 06/03/2015 02:35 PM, Tom Warren wrote: Adds support for Tegra210 SoC and P2571 NVIDIA board. Largely based on T124/Venice2. This is a baseline patchset - more will follow to make things more T210- specific as P2571 peripherals/devices are brought up. Does this add support for a 32-bit or a 64-bit U-Boot? Since T210 is a 64-bit CPU I would have expected a 64-bit U-Boot, yet: a) arch/arm/Kconfig contains: config TEGRA ... select CPU_V7 and this patch doesn't modify that. b) I can built an executable with these patches applied (after manually fixing up some merge problems) with an ARMv7 compiler, but not with an ARMv8 compiler. I think that means this is a 32-bit port. We need a 64-bit port. --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] arm, am33xx: update for siemens am335x based boards
On Tue, Jun 16, 2015 at 02:59:34PM +0200, Heiko Schocher wrote: updates for the siemens am335x based boards: - draco: add delay for DDR3 configuration - change MTD partition layout and add a possibility to redefine MTD layout in board header. - move ubi support to common header file - draco: improve dtb naming - draco: set CONFIG_SYS_CBSIZE to 1024 - add generic env based led Leds can now be defined in Environment - add generic env based dfu button Which gpio is used for the dfu button can be defined through the Environment - set MACH_TYPE only if defined - draco: increase CPU freq to 300MHz - Add time command to siemens am33xx boards - DDR3: increase default tRFC - draco: enable pullup for DFU and ERST pin - change print format DDR3 Signed-off-by: Samuel Egli samuel.e...@siemens.com Acked-by: Heiko Schocher h...@denx.de Reviewed-by: Tom Rini tr...@konsulko.com Signed-off-by: Heiko Schocher h...@denx.de Applied to u-boot/master, thanks! -- 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] [U-Boot, v3, 2/2] common: cmd_part: start and size sub-commands introduction
On Mon, Jun 15, 2015 at 09:35:05PM +0200, Paul Kocialkowski wrote: This introduces the part start and part size sub-commands. The purpose of these is to store the start block and size of a partition in a variable, given the device and partition number. This allows reading raw data that fits a single partition more easily. For instance, this could be used to figure out the start block and size of a kernel partition when a partition table is present, given the partition number. Signed-off-by: Paul Kocialkowski cont...@paulk.fr Acked-by: Stephen Warren swar...@nvidia.com After changing it to use LBAF instead of %lx to fix some warnings, applied to u-boot/master, thanks! -- 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] [U-Boot, 1/2] ti: armv7: enable EXT support in SPL (using ti_armv7_common.h)
On Tue, Jun 16, 2015 at 03:00:09PM +0200, Guillaume GARDET wrote: Tested on Pandaboard (rev. A3) and Beagleboard xM (rev. B). Compilation tested on TI armv7 boards and OMAP boards from other vendors. Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Tom Rini tr...@konsulko.com Reviewed-by: Tom Rini tr...@konsulko.com Applied to u-boot/master, thanks! -- 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] siemens,am33x,rastaban: add rastaban config
On Mon, Jun 15, 2015 at 02:56:41PM +0200, Heiko Schocher wrote: rastaban is a draco version with more flash, more RAM and faster CPU. Number of partitions is the same but rootfs partition is different. Signed-off-by: Samuel Egli samuel.e...@siemens.com Acked-by: Heiko Schocher h...@denx.de Reviewed-by: Tom Rini tr...@konsulko.com Applied to u-boot/master, thanks! -- 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] keystone2: use correct EFUSE_BOOTROM fileds to configure speed
On Mon, Jun 15, 2015 at 08:54:15AM -0400, Vitaly Andrianov wrote: The get_max_arm_speed() and get_max_dev_speed() used wrong register fields to get the maximum speeds. This commit fixes the bug. Signed-off-by: Vitaly Andrianov vita...@ti.com Reviewed-by: Tom Rini tr...@konsulko.com Applied to u-boot/master, thanks! -- 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] [U-Boot,5/5] Make ubifs selectable by Kconfig
On Wed, Jun 10, 2015 at 10:41:03AM +0200, Lars Poeschel wrote: Users who want to use ubifs can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de Applied to u-boot/master, thanks! -- 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] siemens,am33x,thuban: rename dxr2 to thuban
On Mon, Jun 15, 2015 at 02:57:15PM +0200, Heiko Schocher wrote: Update new naming scheme. Signed-off-by: Samuel Egli samuel.e...@siemens.com Acked-by: Heiko Schocher h...@denx.de Reviewed-by: Tom Rini tr...@konsulko.com Applied to u-boot/master, thanks! -- 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] [U-Boot,1/5] Make RBTREE selectable by Kconfig
Hey Tom, On Fri, Jun 19, 2015 at 3:24 PM, Tom Rini tr...@konsulko.com wrote: On Wed, Jun 10, 2015 at 10:40:59AM +0200, Lars Poeschel wrote: Users who want to use RBTREE can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de Applied to u-boot/master, thanks! Please note the discussion on this. Did you mean to apply it? Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Make RBTREE selectable by Kconfig
On Fri, Jun 19, 2015 at 03:39:44PM -0500, Joe Hershberger wrote: On Fri, Jun 19, 2015 at 3:33 PM, Tom Rini tr...@konsulko.com wrote: On Wed, Jun 10, 2015 at 08:49:28AM -0500, Joe Hershberger wrote: Hi Lars, On Wed, Jun 10, 2015 at 3:40 AM, Lars Poeschel poesc...@lemonage.de wrote: Users who want to use RBTREE can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de --- I beat you to it: http://lists.denx.de/pipermail/u-boot/2015-May/214261.html Also, you need to use the tools/moveconfig.py tool to update the headers and defconfigs. So... NAK Oh blarg, I missed this part somehow, dang it.. So now what? If you haven't pushed it yet you can back it out, right? Yay for getting side-tracked. Dropping this series on the floor. -- 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] [PATCH] mmc: bcm2835_sdhci: Restore original delay behavior
On Friday, June 19, 2015 at 11:39:41 PM, Marek Vasut wrote: Patch 33fe2fb8df01647f97a7bce96a1c7781a7f6d253 titled mmc: bcm283x: Remove get_timer_us() from mmc driver incorrectly replaced ad-hoc get_timer_us() function with a plain get_timer(). The get_timer() operates in mSec units instead of uSec though, which caused very slow operation of the driver. Restore the original behavior of the driver, but avoid get_timer_us() and use timer_get_us() instead. The later is part of the standard API. Signed-off-by: Marek Vasut ma...@denx.de Cc: Jakub Kiciński moorr...@wp.pl Cc: Stephen Warren swar...@wwwdotorg.org Stephen/Jakub, can you please test this one one more time ? If it works, it'd be nice if this could be applied to current relase 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 3/4] ARM: mmc: bcm283x: Remove get_timer_us() from mmc driver
On Thursday, June 18, 2015 at 02:51:18 PM, Jakub Kiciński wrote: On Thu, 18 Jun 2015 14:35:27 +0200, Marek Vasut wrote: On Wednesday, June 17, 2015 at 06:13:03 PM, Jakub Kiciński wrote: On Wed, 17 Jun 2015 12:44:15 +0200, Marek Vasut wrote: On Tuesday, June 16, 2015 at 05:44:06 AM, Stephen Warren wrote: On 05/04/2015 02:54 PM, Marek Vasut wrote: The get_timer_us() function is something which is no longer existing in case we use generic timer framework, so replace it with get_timer(). Marek, This patch causes saveenv to got from almost no time to nearly 50s on my RPi model A+. Can you take a look at that please? Can you try the attached diff ? ;-/ I think I mistakenly used get_timer(), which returns msecs instead of timer_get_us() which reports usecs, sorry. I can confirm this solves the regression. That's not a regression, that was a bug ;-) Ach OK, I thought Stephen said that MMC used to be fast before the offending patch ;) Anyway I don't really know what's the difference and wikipedia says regression is a bug too so we may both be right :P I always considered it to be [1] 2c , maybe I'm wrong though ;-) Just recently I thought I finally figured out the difference too, but now you surely made me unsure again :) 2 : a trend or shift toward a lower or less perfect state: as c : reversion to an earlier mental or behavioral level [1] http://www.merriam-webster.com/dictionary/regression Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: bcm2835_sdhci: Restore original delay behavior
Patch 33fe2fb8df01647f97a7bce96a1c7781a7f6d253 titled mmc: bcm283x: Remove get_timer_us() from mmc driver incorrectly replaced ad-hoc get_timer_us() function with a plain get_timer(). The get_timer() operates in mSec units instead of uSec though, which caused very slow operation of the driver. Restore the original behavior of the driver, but avoid get_timer_us() and use timer_get_us() instead. The later is part of the standard API. Signed-off-by: Marek Vasut ma...@denx.de Cc: Jakub Kiciński moorr...@wp.pl Cc: Stephen Warren swar...@wwwdotorg.org --- drivers/mmc/bcm2835_sdhci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c index 078ef05..227d2df 100644 --- a/drivers/mmc/bcm2835_sdhci.c +++ b/drivers/mmc/bcm2835_sdhci.c @@ -69,11 +69,11 @@ static inline void bcm2835_sdhci_raw_writel(struct sdhci_host *host, u32 val, * (Which is just as well - otherwise we'd have to nobble the DMA engine * too) */ - while (get_timer(bcm_host-last_write) bcm_host-twoticks_delay) + while (timer_get_us() - bcm_host-last_write bcm_host-twoticks_delay) ; writel(val, host-ioaddr + reg); - bcm_host-last_write = get_timer(0); + bcm_host-last_write = timer_get_us(); } static inline u32 bcm2835_sdhci_raw_readl(struct sdhci_host *host, int reg) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 0/7] spi: cadence_qspi: optimize fix indirect rd-writes
Thanks Stefan, -Original Message- From: Stefan Roese [mailto:s...@denx.de] Sent: Thursday, June 18, 2015 11:16 PM To: Vikas MANOCHA Cc: u-boot@lists.denx.de; grmo...@opensource.altera.com; dingu...@opensource.altera.com; jt...@openedev.com Subject: Re: [PATCH RESEND 0/7] spi: cadence_qspi: optimize fix indirect rd-writes Hi Vikas, On 18.06.2015 20:05, Vikas MANOCHA wrote: snip $ make -s -j10 Error: arch/arm/dts/socfpga.dtsi:637.5-6 syntax error FATAL ERROR: Unable to parse input tree Error: arch/arm/dts/socfpga.dtsi:637.5-6 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [arch/arm/dts/socfpga_arria5_socdk.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [arch/arm/dts/socfpga_cyclone5_socdk.dtb] Error 1 Error: arch/arm/dts/socfpga.dtsi:637.5-6 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [arch/arm/dts/socfpga_cyclone5_socrates.dtb] Error 1 The socfpga.dtsi has incorrect syntax. Here a quick fix for this - please add this to your next version. And please also compile-test for e.g. socrates. You are right, semicolon has to be replaced with comma. I will fix it in next version do the compile-test also. And please also take care of the correct indentation. $ gd diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi index a2a2029..448870e 100644 --- a/arch/arm/dts/socfpga.dtsi +++ b/arch/arm/dts/socfpga.dtsi @@ -633,8 +633,8 @@ #address-cells = 1; #size-cells = 0; reg = 0xff705000 0x1000, - 0xffa0 0x1000; - 0x 0x0010; + 0xffa0 0x1000, + 0x 0x0010; interrupts = 0 151 4; clocks = qspi_clk; ext-decoder = 0; /* external decoder */ Okay. After installing the resulting image on the SoCrates, I get the following error while reading from SD-card: = sf probe SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR = sf read 10 0 10 QSPI: indirect completion status error with reg 0x000c SF: 1048576 bytes @ 0x0 Read: ERROR So there seems to be something breaking the SoCFPGA Cadence QSPI support. Any idea whats going wrong here? It means indirect read was not successful. Can you please: - please check if sf write is also causing some error or is working fine. Same error. - git bisect or cherry-pick to find out which patch is breaking the read functionality. This one is the first introducing this breakage: spi: cadence_qspi: fix base trigger address transfer start address Ok, can you confirm applying patches upto ( including) spi: cadence_qspi: fix indirect read/write start address , read/write to flash are working fine. The point is if after applying above mentioned patch (...: fix indirect read/write start address), Read/write are working fine, then trigger_base value of 0xFFA00_ should also work fine. Can you please modify the trigger_base value from 0x0 to 0xFFA0_ in Socfpga.dtsi check. If it works, it would mean both (socfpga stv0991) are behaving same. Rgds, Vikas Here the output from the complete patchset with DEBUG enabled: = sf probe cadence_spi_ofdata_to_platdata: regbase=ff705000 flashbase=ffa0 trigger_base= max-frequency=50 page-size=256 cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 100Hz Div 0xf cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 100Hz Div 0xf cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 50Hz Div 0xf SF: Read data capture delay calibrated to 7 (0 - 15) cadence_spi_set_speed: speed=100 cadence_spi_xfer: len=1 [bytes] cadence_qspi_apb_chipselect : chipselect 0 decode 0 cadence_spi_xfer: len=5 [bytes] cadence_qspi_apb_chipselect : chipselect 0 decode 0 SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 100Hz Div 0xf cadence_spi_set_speed: speed=100 = sf read 20 10 1 cadence_spi_xfer: len=5 [bytes] cadence_qspi_apb_chipselect : chipselect 0 decode 0 cadence_spi_xfer: len=65536 [bytes] cadence_qspi_apb_chipselect : chipselect 0 decode 0 QSPI: indirect completion status error with reg 0x000c SF: 65536 bytes @ 0x10 Read: ERROR HTP. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 4/5] Make lzo decompression selectable by Kconfig
On Wed, Jun 10, 2015 at 10:41:02AM +0200, Lars Poeschel wrote: Users who want to use lzo decompression can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de Applied to u-boot/master, thanks! -- 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] [U-Boot, 2/5] Make MTD_PARTITIONS selectable by Kconfig
On Wed, Jun 10, 2015 at 10:41:00AM +0200, Lars Poeschel wrote: Users who want to use MTD_PARTITIONS can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de Applied to u-boot/master, thanks! -- 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] [U-Boot,1/5] Make RBTREE selectable by Kconfig
On Wed, Jun 10, 2015 at 10:40:59AM +0200, Lars Poeschel wrote: Users who want to use RBTREE can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de Applied to u-boot/master, thanks! -- 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] [U-Boot,3/5] Make ubi selectable by Kconfig
On Wed, Jun 10, 2015 at 10:41:01AM +0200, Lars Poeschel wrote: Users who want to use ubi can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de Applied to u-boot/master, thanks! -- 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-usb/master
On Fri, Jun 19, 2015 at 08:16:46PM +0200, Marek Vasut wrote: The following changes since commit c6265f7f3410b5e5763181cdd123a3f6fcd9fd58: CPCI4052: Remove CONFIG_SYS_LONGHELP (2015-06-18 16:19:00 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git HEAD for you to fetch changes up to de451493f1b6dfcc572763be421500754bfc6b2f: usb: kbd: Disable idle input reports when we do not need them (2015-06-19 14:33:29 +0200) Applied to u-boot/master, thanks! -- 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] [U-Boot, v2] ARM: phytec: pcm051: select board revision by Kconfig
On Thu, Jun 04, 2015 at 10:07:36AM +0200, Lars Poeschel wrote: From: Lars Poeschel poesc...@lemonage.de This add a Kconfig entry that allows to set the board revision in menuconfig. So the deprecated CONFIG_SYS_EXTRA_OPTIONS is no longer needed for this boad. Signed-off-by: Lars Poeschel poesc...@lemonage.de Doesn't work for me: arm: + pcm051_rev3 +(pcm051_rev3) scripts/Makefile.build:56: board/phytec/pcm051rev3/Makefile: No such file or directory +(pcm051_rev3) make[2]: *** No rule to make target `board/phytec/pcm051rev3/Makefile'. Stop. +(pcm051_rev3) make[1]: *** [board/phytec/pcm051rev3] Error 2 +(pcm051_rev3) make: *** [sub-make] Error 2 arm: + am335x_boneblack_vboot +(am335x_boneblack_vboot) make[1]: *** [checkdtc] Error 1 +(am335x_boneblack_vboot) make: *** [sub-make] Error 2 arm: + pcm051_rev1 +(pcm051_rev1) scripts/Makefile.build:56: board/phytec/pcm051rev1/Makefile: No such file or directory +(pcm051_rev1) make[2]: *** No rule to make target `board/phytec/pcm051rev1/Makefile'. Stop. +(pcm051_rev1) make[1]: *** [board/phytec/pcm051rev1] Error 2 +(pcm051_rev1) make: *** [sub-make] Error 2 -- 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] [PATCH 1/5] Make RBTREE selectable by Kconfig
On Wed, Jun 10, 2015 at 08:49:28AM -0500, Joe Hershberger wrote: Hi Lars, On Wed, Jun 10, 2015 at 3:40 AM, Lars Poeschel poesc...@lemonage.de wrote: Users who want to use RBTREE can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de --- I beat you to it: http://lists.denx.de/pipermail/u-boot/2015-May/214261.html Also, you need to use the tools/moveconfig.py tool to update the headers and defconfigs. So... NAK Oh blarg, I missed this part somehow, dang it.. So now what? -- 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] [PATCH 1/5] Make RBTREE selectable by Kconfig
On Fri, Jun 19, 2015 at 3:33 PM, Tom Rini tr...@konsulko.com wrote: On Wed, Jun 10, 2015 at 08:49:28AM -0500, Joe Hershberger wrote: Hi Lars, On Wed, Jun 10, 2015 at 3:40 AM, Lars Poeschel poesc...@lemonage.de wrote: Users who want to use RBTREE can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de --- I beat you to it: http://lists.denx.de/pipermail/u-boot/2015-May/214261.html Also, you need to use the tools/moveconfig.py tool to update the headers and defconfigs. So... NAK Oh blarg, I missed this part somehow, dang it.. So now what? If you haven't pushed it yet you can back it out, right? -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,1/2] common: cmd_part: Proper alignment
On Mon, Jun 15, 2015 at 09:35:04PM +0200, Paul Kocialkowski wrote: This fixes a misaligned declaration. Signed-off-by: Paul Kocialkowski cont...@paulk.fr Applied to u-boot/master, thanks! -- 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] [U-Boot, 2/2] ti: omap4: remove CONFIG_SPL_EXT_SUPPORT from ti_omap4_common.h since it is now in ti_armv7_common.h
On Tue, Jun 16, 2015 at 03:00:10PM +0200, Guillaume GARDET wrote: Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr Cc: Tom Rini tr...@konsulko.com Reviewed-by: Tom Rini tr...@konsulko.com Applied to u-boot/master, thanks! -- 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] ARM: DRA7: Change configuration to prevent DDR reset control from EMIF
On Tue, Jun 16, 2015 at 08:29:01AM -0500, Nishanth Menon wrote: DRA7/AM57xx devices can be operated in many different configurations. When the SoC is supposed to support a configuration where low power mode state may involve the SoC completely powered off and DDR is in self refresh, SoC EMIF controller should not be the master of the reset signal and an external entity might be in control of things. The default configuration of Linux on TI evms involve not powering off the voltage rails (due to various reasons including reliability concerns) and must not allow DDR reset to be controlled by EMIF. On platforms where external entity might control the reset signal, this configuration will be a dont care. Fixes: 536d87470869 (ARM: DRA7: Update DDR IO registers) Tested-by: Keerthy j-keer...@ti.com Acked-by: Brad Griffis bgrif...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Reviewed-by: Tom Rini tr...@konsulko.com Applied to u-boot/master, thanks! -- 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] [U-Boot,v2,1/3] am43xx: Update CONFIG_SPL_TEXT_BASE
On Tue, Jun 16, 2015 at 08:23:37PM +0530, Mugunthan V N wrote: From: Tom Rini tr...@konsulko.com With 1.2 silicon this is now the documented starting usable point for downloading images to (and corrects a problem with peripheral booting with prior silicon). Prior silicon is OK using this address as well. Signed-off-by: Tom Rini tr...@konsulko.com Signed-off-by: Mugunthan V N mugunthan...@ti.com Applied to u-boot/master, thanks! -- 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] [U-Boot,v2,3/3] am43xx_evm: add eth boot support
On Tue, Jun 16, 2015 at 08:23:39PM +0530, Mugunthan V N wrote: add cpsw ethernet boot mode support to download spl and u-boot.img via tftp protocol. Also adding a seperate config for ethernet boot mode as the default build falcon mode and environment on MMC is defined for ethernet boot mode environment should be set to nowhere. Signed-off-by: Mugunthan V N mugunthan...@ti.com Reviewed-by: Tom Rini tr...@konsulko.com Applied to u-boot/master, thanks! -- 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] [U-Boot,v2,2/3] am43xx_evm: add usb host boot support
On Tue, Jun 16, 2015 at 08:23:38PM +0530, Mugunthan V N wrote: While booting via usb host mode, ROM uses DMA to copy MLO over USB so ARM internal RAM cannot be used. Adding USB host boot support by introducing new config target which sets SPL_TEXT_BASE to OCMC ram. Signed-off-by: Mugunthan V N mugunthan...@ti.com Reviewed-by: Tom Rini tr...@konsulko.com Applied to u-boot/master, thanks! -- 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] ARM: BeagleBoard-X15: Enable VTT regulator
On Tue, Jun 16, 2015 at 08:36:05PM +0530, Lokesh Vutla wrote: BeagleBoard-X15 uses a vtt regulator for DDR3 termination and this is controlled by gpio7_11. Configuring gpio7_11. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com Reviewed-by: Tom Rini tr...@konsulko.com Applied to u-boot/master, thanks! -- 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] [U-Boot,v2] README: Describe CONFIG_SYS_NO_FLASH
On Fri, Jun 19, 2015 at 08:25:59PM +1200, Chris Packham wrote: Unlike most configuration options defining this actually disables support for a feature (parallel flash). Eventually the logic behind this should probably be flipped so that '#ifndef CONFIG_SYS_NO_FLASH' becomes '#ifdef CONFIG_HAS_PARALLEL_FLASH' but for now lets document the existing behaviour. Signed-off-by: Chris Packham judge.pack...@gmail.com Reviewed-by: Stefan Roese s...@denx.de Applied to u-boot/master, thanks! -- 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] [PATCH 1/5] Make RBTREE selectable by Kconfig
On Wed, Jun 10, 2015 at 10:40:59AM +0200, Lars Poeschel wrote: Users who want to use RBTREE can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de For the record, not applied to u-boot/master, thanks! -- 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] [PATCH 2/5] Make MTD_PARTITIONS selectable by Kconfig
On Wed, Jun 10, 2015 at 10:41:00AM +0200, Lars Poeschel wrote: Users who want to use MTD_PARTITIONS can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de For the record, not applied to u-boot/master, thanks! -- 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] [PATCH 3/5] Make ubi selectable by Kconfig
On Wed, Jun 10, 2015 at 10:41:01AM +0200, Lars Poeschel wrote: Users who want to use ubi can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de For the record, not applied to u-boot/master, thanks! -- 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] [PATCH 5/5] Make ubifs selectable by Kconfig
On Wed, Jun 10, 2015 at 10:41:03AM +0200, Lars Poeschel wrote: Users who want to use ubifs can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de For the record, not applied to u-boot/master, thanks! -- 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] [PATCH 4/5] Make lzo decompression selectable by Kconfig
On Wed, Jun 10, 2015 at 10:41:02AM +0200, Lars Poeschel wrote: Users who want to use lzo decompression can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel poesc...@lemonage.de For the record, not applied to u-boot/master, thanks! -- 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] [PATCH RESEND 0/7] spi: cadence_qspi: optimize fix indirect rd-writes
Hi Vikas, On 18.06.2015 20:05, Vikas MANOCHA wrote: snip $ make -s -j10 Error: arch/arm/dts/socfpga.dtsi:637.5-6 syntax error FATAL ERROR: Unable to parse input tree Error: arch/arm/dts/socfpga.dtsi:637.5-6 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [arch/arm/dts/socfpga_arria5_socdk.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: *** [arch/arm/dts/socfpga_cyclone5_socdk.dtb] Error 1 Error: arch/arm/dts/socfpga.dtsi:637.5-6 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [arch/arm/dts/socfpga_cyclone5_socrates.dtb] Error 1 The socfpga.dtsi has incorrect syntax. Here a quick fix for this - please add this to your next version. And please also compile-test for e.g. socrates. You are right, semicolon has to be replaced with comma. I will fix it in next version do the compile-test also. And please also take care of the correct indentation. $ gd diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi index a2a2029..448870e 100644 --- a/arch/arm/dts/socfpga.dtsi +++ b/arch/arm/dts/socfpga.dtsi @@ -633,8 +633,8 @@ #address-cells = 1; #size-cells = 0; reg = 0xff705000 0x1000, - 0xffa0 0x1000; - 0x 0x0010; + 0xffa0 0x1000, + 0x 0x0010; interrupts = 0 151 4; clocks = qspi_clk; ext-decoder = 0; /* external decoder */ Okay. After installing the resulting image on the SoCrates, I get the following error while reading from SD-card: = sf probe SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR = sf read 10 0 10 QSPI: indirect completion status error with reg 0x000c SF: 1048576 bytes @ 0x0 Read: ERROR So there seems to be something breaking the SoCFPGA Cadence QSPI support. Any idea whats going wrong here? It means indirect read was not successful. Can you please: - please check if sf write is also causing some error or is working fine. Same error. - git bisect or cherry-pick to find out which patch is breaking the read functionality. This one is the first introducing this breakage: spi: cadence_qspi: fix base trigger address transfer start address Here the output from the complete patchset with DEBUG enabled: = sf probe cadence_spi_ofdata_to_platdata: regbase=ff705000 flashbase=ffa0 trigger_base= max-frequency=50 page-size=256 cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 100Hz Div 0xf cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 100Hz Div 0xf cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 50Hz Div 0xf SF: Read data capture delay calibrated to 7 (0 - 15) cadence_spi_set_speed: speed=100 cadence_spi_xfer: len=1 [bytes] cadence_qspi_apb_chipselect : chipselect 0 decode 0 cadence_spi_xfer: len=5 [bytes] cadence_qspi_apb_chipselect : chipselect 0 decode 0 SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB SF: Warning - Only lower 16MiB accessible, Full access #define CONFIG_SPI_FLASH_BAR cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 100Hz Div 0xf cadence_spi_set_speed: speed=100 = sf read 20 10 1 cadence_spi_xfer: len=5 [bytes] cadence_qspi_apb_chipselect : chipselect 0 decode 0 cadence_spi_xfer: len=65536 [bytes] cadence_qspi_apb_chipselect : chipselect 0 decode 0 QSPI: indirect completion status error with reg 0x000c SF: 65536 bytes @ 0x10 Read: ERROR HTP. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: cf_qspi: fix clamp macro type check compilation warnings
On 5 June 2015 at 04:53, Angelo Dureghello ang...@sysam.it wrote:
Fix clamp macro redefined warning, and clamp type check warnings.
Signed-off-by: Angelo Dureghello ang...@sysam.it
---
drivers/spi/cf_qspi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/cf_qspi.c b/drivers/spi/cf_qspi.c
index 834c5bd..c4bafe0 100644
--- a/drivers/spi/cf_qspi.c
+++ b/drivers/spi/cf_qspi.c
@@ -19,7 +19,6 @@
DECLARE_GLOBAL_DATA_PTR;
-#define clamp(x, low, high) (min(max(low, x), high))
#define to_cf_qspi_slave(s) container_of(s, struct cf_qspi_slave, slave)
struct cf_qspi_slave {
@@ -119,7 +118,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
if (max_hz == 0) /* Go as fast as possible */
dev-qmr = 2u;
else /* Get the closest baud rate */
- dev-qmr = clamp(((gd-bus_clk 2) + max_hz - 1)/max_hz,
+ dev-qmr = clamp_val(((gd-bus_clk 2) + max_hz - 1)/max_hz,
Yes, there is a common macro in include/linux - can you check this
clamp or clamp_val and
test it accordingly.
2u, 255u);
/* Map mode to QMR[CPOL] and QMR[CPHA] */
--
2.1.4
thanks!
--
Jagan | openedev.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 19/22] sunxi: musb: Move musb config and platdata to the sunxi-musb glue
On Wed, 2015-06-17 at 21:34 +0200, Hans de Goede wrote: Move the musb config and platdata to the sunxi-musb glue, which is where it really belongs. This is preparation patch for adding device-model support for the sunxi-musb-host code. Signed-off-by: Hans de Goede hdego...@redhat.com --- arch/arm/include/asm/arch-sunxi/usb_phy.h | 7 +++ board/sunxi/board.c | 28 ++--- drivers/usb/musb-new/sunxi.c | 35 ++- 3 files changed, 34 insertions(+), 36 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/usb_phy.h b/arch/arm/include/asm/arch-sunxi/usb_phy.h index 5a9cacb..17d31b8 100644 --- a/arch/arm/include/asm/arch-sunxi/usb_phy.h +++ b/arch/arm/include/asm/arch-sunxi/usb_phy.h @@ -19,3 +19,10 @@ void sunxi_usb_phy_power_off(int index); int sunxi_usb_phy_vbus_detect(int index); int sunxi_usb_phy_id_detect(int index); void sunxi_usb_phy_enable_squelch_detect(int index, int enable); + +/* Not really phy related, but we have to declare this somewhere ... */ I guess arch/arm/include/asm/arch-sunxi/usbc.h isn't any better? With it here or there: Acked-by: Ian Campbell i...@hellion.org.uk +#if defined(CONFIG_MUSB_HOST) || defined(CONFIG_MUSB_GADGET) +void sunxi_musb_board_init(void); +#else +#define sunxi_musb_board_init() +#endif Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/22] sunxi: musb: Add id pin support
On Wed, 2015-06-17 at 21:34 +0200, Hans de Goede wrote: When in host mode check if there is a host cable inserted into the otg port by checking the id pin. If there is no host cable return an error to make usb_lowlevel_init() exit early, rather then waiting for 1 second for a device which will never show up. Signed-off-by: Hans de Goede hdego...@redhat.com I guess the defconfig fiddling is here because this is the culmination of these three patches which makes it useful to set this value? In which case: Acked-by: Ian Campbell i...@hellion.org.uk Although I'd have been inclined to do it where the Kconfig option was added (ack to that too if you want to move). Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/4] dm: sf: Add Atmel DataFlash spi flash driver
On Tue, May 19, 2015 at 8:26 AM, Wang Haikun haikun.w...@freescale.com wrote: On 5/18/2015 9:28 PM, Haikun Wang wrote: Atmel DataFlash chips have commands different from common spi flash commands. Atmel DataFlash also have special page-size. This driver add support for accessing Atmel DataFlash. It is based on the Driver Model. Example: = sf probe 1:0 SPI DataFlash: Detected AT45DB021B with page size 264 Bytes, erase size 264 Bytes, total 264 KiB, revision d = sf erase 0 42000 SF: 270336 bytes @ 0x0 Erased: OK = mw.l 8200 45444342 2 = sf write 8200 0 42000 SF: 270336 bytes @ 0x0 Written: OK = sf read 8300 0 42000 SF: 270336 bytes @ 0x0 Read: OK = cmp.b 8200 8300 42000 Total of 270336 byte(s) were the same Signed-off-by: Haikun Wang haikun.w...@freescale.com --- Verified with AT45DB021B on LS1021AQDS. Changes in v5: - Change CONFIG_DM_SF_DATAFLASH to CONFIG_SF_DATAFLASH Changes in v4: - Use dev_get_priv and dev_get_uclass_priv - Add test log to commit message Changes in v3: - 1. Rename file spi_dataflash.c to sf_dataflash.c - 2. Add comment for array dataflash_data Changes in v2: - 1. Correct comment style - 2. Use get_timer in dataflash_waitready to check whether timeout - 3. Remove struct spi_flash * in struct dataflash, and get it from udevice-uclass_priv - 4. Replace spi_flash_write_common with spi_flash_cmd_write - 5. Replace spi_flash_read with spi_flash_cmd_read - 6. Change type of varible status form char to u8 in dataflash_status - 7. Change add_dataflash's argument type due to change 3 - 8. Add claim_bus and release_bus in erase/write/read due to change 4 5 Changes in v1: None drivers/mtd/spi/Makefile | 1 + drivers/mtd/spi/sf_dataflash.c | 711 + 2 files changed, 712 insertions(+) create mode 100644 drivers/mtd/spi/sf_dataflash.c Reviewed by: Chakra Divi cd...@openedev.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] arm: ls102xa: Enable Driver Model SPI for ls1021atwr
On 18 June 2015 at 12:24, Jagan Teki jt...@openedev.com wrote: On 18 June 2015 at 07:50, Wang Haikun haikun.w...@freescale.com wrote: On 6/17/2015 8:30 PM, Simon Glass wrote: Hi, On 17 June 2015 at 03:36, Bin Meng bmeng...@gmail.com wrote: Hi Haikun, On Mon, May 18, 2015 at 9:25 PM, Haikun Wang haikun.w...@freescale.com wrote: From: Haikun Wang haikun.w...@freescale.com Enable Driver Model SPI for ls1021atwr board. DSPI and QSPI only be enabled when boot from QSPI. DSPI and QSPI are compatible under Driver Model SPI. Signed-off-by: Haikun Wang haikun.w...@freescale.com Change-Id: I6342807da7725ae8b678952117c8758c75a61d3d Where is this commit id? I couldn't see it on git log Reviewed-on: http://git.am.freescale.net:8181/33447 Best regards, Wang Haikun Is this URL Freescale internal? I cannot access it. Looks like it. BTW patman will remove these Gerrit tags automatically. Yes, it is our internal URL. I forget to remove it. It couldn't be better if it will be removed automatically. I will remove if something not remove automatically. Anyone have any comments on these patch-set, I'm planning to take these. https://patchwork.ozlabs.org/patch/473391/ https://patchwork.ozlabs.org/patch/473392/ https://patchwork.ozlabs.org/patch/473393/ https://patchwork.ozlabs.org/patch/473394/ Tested-by: Review Code-CDREVIEW cdrev...@freescale.com Reviewed-by: Prabhakar Kushwaha prabha...@freescale.com --- Changes in v3: - IS_ENABLED(CONFIG_XXX) is only work with configure option in Kconfig, and DM core code use IS_ENABLED(), so configure option in head file can't work, so remove CONFIG_OF_CONTROL CONFIG_OF_SEPARATE CONFIG_DM CONFIG_DM_SPI Changes in v2: - Move all changes inside of CONFIG_QSPI_BOOT Changes in v1: None include/configs/ls1021atwr.h | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 729205f..13e3aa4 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -229,16 +229,22 @@ #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION -/* QSPI */ +/* SPI */ #ifdef CONFIG_QSPI_BOOT +/* QSPI */ #define CONFIG_FSL_QSPI #define QSPI0_AMBA_BASE0x4000 #define FSL_QSPI_FLASH_SIZE(1 24) #define FSL_QSPI_FLASH_NUM 2 +#define CONFIG_SPI_FLASH_STMICRO + +/* DM SPI */ +#if defined(CONFIG_FSL_DSPI) || defined(CONFIG_FSL_QSPI) #define CONFIG_CMD_SF +#define CONFIG_DM_SPI_FLASH #define CONFIG_SPI_FLASH -#define CONFIG_SPI_FLASH_STMICRO +#endif #endif /* thanks! -- Jagan | openedev. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/22] sunxi: Kconfig: Enable CONFIG_USB and friends by default on sunxi
On Wed, 2015-06-17 at 21:34 +0200, Hans de Goede wrote: Start using the new Kconfig options which are available for most of the USB settings now. This also allows us to use CONFIG_USB_EHCI_HCD=y in defconfig files for new boards instead of CONFIG_SYS_EXTRA_OPTIONS=USB_EHCI. Should there not be a raft of defconfig changes at the same time? Or is that nice but not necessary at this stage? Signed-off-by: Hans de Goede hdego...@redhat.com --- board/sunxi/Kconfig| 9 + include/configs/sunxi-common.h | 5 - 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 6a19f85..8d55cd6 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -594,4 +594,13 @@ config CMD_SETEXPR config CMD_NET default y +config CMD_USB + default y + +config USB + default y + +config USB_STORAGE + default y + endif diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 063abd5..e2371a1 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -338,11 +338,6 @@ extern int soft_i2c_gpio_scl; #define CONFIG_MUSB_PIO_ONLY #endif -#if defined CONFIG_USB_EHCI || defined CONFIG_USB_MUSB_SUNXI -#define CONFIG_CMD_USB -#define CONFIG_USB_STORAGE -#endif - #ifdef CONFIG_USB_KEYBOARD #define CONFIG_CONSOLE_MUX #define CONFIG_PREBOOT ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/22] sunxi: musb: Use device-model for musb host mode
On Wed, 2015-06-17 at 21:34 +0200, Hans de Goede wrote: [...] + * Bind the driver directly for now as musb linux kernel support is + * still pending upstream so our dts files do not have the necessay necessary. Otherwise: Acked-by: Ian Campbell i...@hellion.org.uk So far as this being a sunxi change goes, although I think this probably needs other acks from the CC line too. Ian. + * nodes yet. TODO: Remove this as soon as the dts nodes are in place + * and bind by compatible instead. + */ + device_bind_driver(dm_root(), sunxi-musb, sunxi-musb, dev); +#else musb_register(musb_plat, NULL, (void *)SUNXI_USB0_BASE); +#endif } ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 17/22] sunxi: musb: Move vbus check to sunxi_musb_enable
On Wed, 2015-06-17 at 21:34 +0200, Hans de Goede wrote: This way it can be re-checked on usb reset. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/22] sunxi: usb-phy: Add support for reading otg id pin value
On Wed, 2015-06-17 at 21:33 +0200, Hans de Goede wrote: Add support for reading the id pin value of the otg connector to the usb phy code. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 22/22] sunxi: ga10h: Enable both otg and regular usb host controllers
On Wed, 2015-06-17 at 21:34 +0200, Hans de Goede wrote: This allows using devices plugged into both ports of the tablet. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/22] sunxi: Kconfig: Enable CONFIG_USB and friends by default on sunxi
Hi, On 19-06-15 09:46, Ian Campbell wrote: On Wed, 2015-06-17 at 21:34 +0200, Hans de Goede wrote: Start using the new Kconfig options which are available for most of the USB settings now. This also allows us to use CONFIG_USB_EHCI_HCD=y in defconfig files for new boards instead of CONFIG_SYS_EXTRA_OPTIONS=USB_EHCI. Should there not be a raft of defconfig changes at the same time? Or is that nice but not necessary at this stage? There could be a of defconfig changes at the same time, but it is not necessary, so I decided to wait with cleaning this up till later. I would like to first see all the other stuff from CONFIG_SYS_EXTRA_OPTIONS by Kconfig-ified too, and then we can cleanup all the CONFIG_SYS_EXTRA_OPTIONS usage in one go. Regards, Hans Signed-off-by: Hans de Goede hdego...@redhat.com --- board/sunxi/Kconfig| 9 + include/configs/sunxi-common.h | 5 - 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 6a19f85..8d55cd6 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -594,4 +594,13 @@ config CMD_SETEXPR config CMD_NET default y +config CMD_USB + default y + +config USB + default y + +config USB_STORAGE + default y + endif diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 063abd5..e2371a1 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -338,11 +338,6 @@ extern int soft_i2c_gpio_scl; #define CONFIG_MUSB_PIO_ONLY #endif -#if defined CONFIG_USB_EHCI || defined CONFIG_USB_MUSB_SUNXI -#define CONFIG_CMD_USB -#define CONFIG_USB_STORAGE -#endif - #ifdef CONFIG_USB_KEYBOARD #define CONFIG_CONSOLE_MUX #define CONFIG_PREBOOT ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] sunxi: musb: Fix usb reset handling
On Friday, June 19, 2015 at 03:07:04 PM, Hans de Goede wrote:
Hi,
On 19-06-15 14:35, Marek Vasut wrote:
On Sunday, June 14, 2015 at 12:40:11 PM, Hans de Goede wrote:
Hi Ian, Paul,
Here is a patch to fix the problems where most usb devices will no
longer work after a usb reset , when connected to the otg controller
in host mode + a related cleanup patch.
Ian I would like to send out a PR with these 2 as fixed for v2015.07,
can you review them please? Note I've not tested this with the otg in
gadget mode, but we do not have gadget mode enabled by default anywhere
atm, so I still consider this suitable as a bugfix for v2015.07.
Paul, can you test these with gadget mode? Specifically if they help the
problem you were seeing when switching roles?
Also this bit from the kernel code for the sunxi glue may be relevant
to your problems:
if ((musb-int_usb MUSB_INTR_RESET) !is_host_active(musb))
{
/* ep0 FADDR must be 0 when (re)entering peripheral
mode */ musb_ep_select(musb-mregs, 0);
musb_writeb(musb-mregs, MUSB_FADDR, 0);
}
This is from the interrupt handler in the sunxi-musb glue in the kernel,
maybe we can do the same, and/or maybe we need to do:
/* ep0 FADDR must be 0 when (re)entering peripheral mode */
musb_ep_select(musb-mregs, 0);
musb_writeb(musb-mregs, MUSB_FADDR, 0);
From sunxi_musb_disable?
From my experience sofar we should avoid doing a full reset from
musb_stop
/ sunxi_musb_disable as musb_init_controller never gets re-run, so doing
a full reset leaves things in a bad state where only ep0 still seems to
work, this may be what you were seeing before.
Hi,
do you want me to pick this via u-boot-usb/master ?
No, I've already send a pull-req for them via u-boot-sunxi/master and they
are already merged :)
OK, roger.
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 00/22] Convert musb host mode code to the device-model
Hi, On 19-06-15 15:10, Simon Glass wrote: Hi Hans, On 17 June 2015 at 13:33, Hans de Goede hdego...@redhat.com wrote: Hi Marek and Simon, This series started out with the idea that it would be a nice small project for the weekend, but it turned out to be a bit more work... The main purpose of this series is to convert the musb host mode code to the device-model this has also resulted in various usb fixes / cleanups / reworking to make this possible, both in the generic usb code as well as in the device model usb code. Given that this touches both, I think it is probably best to merge the first 15 patches through Simon's tree like we did last time, then once those are place I can merge the sunxi bits. Note this is intended for v2015.10 (ofcourse). Note that this series is useful for a bunch more boards then just the single one the last patch updates to use musb + ehci + ohci, but that is the one I've been testing with other defconfig-s will be updated with followup patches. Please review. Thanks for putting this together. Actually I'm not sure what musb is. Can you explain what it is used for - it seems to be referred to as a new version of something else. Why do we have musb and non-musb? Is there a README somewhere I could read? musb stands for mentor-graphics usb it is an otg usb2 ip-block used in various SoCs as otg controller. As an otg controller it can be used in both host or peripheral mode. This series converts the code for using it in host-mode to the device-model. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/22] sunxi: Kconfig: Enable CONFIG_USB and friends by default on sunxi
On Fri, 2015-06-19 at 11:37 +0200, Hans de Goede wrote: Hi, On 19-06-15 09:46, Ian Campbell wrote: On Wed, 2015-06-17 at 21:34 +0200, Hans de Goede wrote: Start using the new Kconfig options which are available for most of the USB settings now. This also allows us to use CONFIG_USB_EHCI_HCD=y in defconfig files for new boards instead of CONFIG_SYS_EXTRA_OPTIONS=USB_EHCI. Should there not be a raft of defconfig changes at the same time? Or is that nice but not necessary at this stage? There could be a of defconfig changes at the same time, but it is not necessary, so I decided to wait with cleaning this up till later. OK: Acked-by: Ian Campbell i...@hellion.org.uk I would like to first see all the other stuff from CONFIG_SYS_EXTRA_OPTIONS by Kconfig-ified too, and then we can cleanup all the CONFIG_SYS_EXTRA_OPTIONS usage in one go. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/22] Convert musb host mode code to the device-model
Hi, On 19-06-15 15:10, Simon Glass wrote: Hi Hans, On 17 June 2015 at 13:33, Hans de Goede hdego...@redhat.com wrote: Hi Marek and Simon, This series started out with the idea that it would be a nice small project for the weekend, but it turned out to be a bit more work... The main purpose of this series is to convert the musb host mode code to the device-model this has also resulted in various usb fixes / cleanups / reworking to make this possible, both in the generic usb code as well as in the device model usb code. Given that this touches both, I think it is probably best to merge the first 15 patches through Simon's tree like we did last time, then once those are place I can merge the sunxi bits. Note this is intended for v2015.10 (ofcourse). Note that this series is useful for a bunch more boards then just the single one the last patch updates to use musb + ehci + ohci, but that is the one I've been testing with other defconfig-s will be updated with followup patches. Please review. Thanks for putting this together. Actually I'm not sure what musb is. Can you explain what it is used for - it seems to be referred to as a new version of something else. Why do we have musb and non-musb? Is there a README somewhere I could read? p.s. As for there being both a drivers/usb/musb and a driver/usb/musb-new directoyry, I believe that they both are drivers for the same hardware, but not all boards have been ported to musb-new yet. musb-new is derived from recent kernel code for the musb controller. Regards, Hans Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/22] Convert musb host mode code to the device-model
Hi Hans, On 17 June 2015 at 13:33, Hans de Goede hdego...@redhat.com wrote: Hi Marek and Simon, This series started out with the idea that it would be a nice small project for the weekend, but it turned out to be a bit more work... The main purpose of this series is to convert the musb host mode code to the device-model this has also resulted in various usb fixes / cleanups / reworking to make this possible, both in the generic usb code as well as in the device model usb code. Given that this touches both, I think it is probably best to merge the first 15 patches through Simon's tree like we did last time, then once those are place I can merge the sunxi bits. Note this is intended for v2015.10 (ofcourse). Note that this series is useful for a bunch more boards then just the single one the last patch updates to use musb + ehci + ohci, but that is the one I've been testing with other defconfig-s will be updated with followup patches. Please review. Thanks for putting this together. Actually I'm not sure what musb is. Can you explain what it is used for - it seems to be referred to as a new version of something else. Why do we have musb and non-musb? Is there a README somewhere I could read? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 19/22] sunxi: musb: Move musb config and platdata to the sunxi-musb glue
On Fri, 2015-06-19 at 11:35 +0200, Hans de Goede wrote: Hi, On 19-06-15 09:43, Ian Campbell wrote: On Wed, 2015-06-17 at 21:34 +0200, Hans de Goede wrote: Move the musb config and platdata to the sunxi-musb glue, which is where it really belongs. This is preparation patch for adding device-model support for the sunxi-musb-host code. Signed-off-by: Hans de Goede hdego...@redhat.com --- arch/arm/include/asm/arch-sunxi/usb_phy.h | 7 +++ board/sunxi/board.c | 28 ++--- drivers/usb/musb-new/sunxi.c | 35 ++- 3 files changed, 34 insertions(+), 36 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/usb_phy.h b/arch/arm/include/asm/arch-sunxi/usb_phy.h index 5a9cacb..17d31b8 100644 --- a/arch/arm/include/asm/arch-sunxi/usb_phy.h +++ b/arch/arm/include/asm/arch-sunxi/usb_phy.h @@ -19,3 +19,10 @@ void sunxi_usb_phy_power_off(int index); int sunxi_usb_phy_vbus_detect(int index); int sunxi_usb_phy_id_detect(int index); void sunxi_usb_phy_enable_squelch_detect(int index, int enable); + +/* Not really phy related, but we have to declare this somewhere ... */ I guess arch/arm/include/asm/arch-sunxi/usbc.h isn't any better? Well we do not have that, and I did not feel it was worth adding yet another .h file for just this one function. Ah, my tree had: u-boot.git$ wc -l arch/arm/include/asm/arch-sunxi/usbc.h 24 arch/arm/include/asm/arch-sunxi/usbc.h But it was stale and the file has now gone in sunxi#next. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] sunxi: musb: Fix usb reset handling
Hi,
On 19-06-15 14:35, Marek Vasut wrote:
On Sunday, June 14, 2015 at 12:40:11 PM, Hans de Goede wrote:
Hi Ian, Paul,
Here is a patch to fix the problems where most usb devices will no longer
work after a usb reset , when connected to the otg controller in host
mode + a related cleanup patch.
Ian I would like to send out a PR with these 2 as fixed for v2015.07, can
you review them please? Note I've not tested this with the otg in gadget
mode, but we do not have gadget mode enabled by default anywhere atm, so
I still consider this suitable as a bugfix for v2015.07.
Paul, can you test these with gadget mode? Specifically if they help the
problem you were seeing when switching roles?
Also this bit from the kernel code for the sunxi glue may be relevant
to your problems:
if ((musb-int_usb MUSB_INTR_RESET) !is_host_active(musb)) {
/* ep0 FADDR must be 0 when (re)entering peripheral mode */
musb_ep_select(musb-mregs, 0);
musb_writeb(musb-mregs, MUSB_FADDR, 0);
}
This is from the interrupt handler in the sunxi-musb glue in the kernel,
maybe we can do the same, and/or maybe we need to do:
/* ep0 FADDR must be 0 when (re)entering peripheral mode */
musb_ep_select(musb-mregs, 0);
musb_writeb(musb-mregs, MUSB_FADDR, 0);
From sunxi_musb_disable?
From my experience sofar we should avoid doing a full reset from musb_stop
/ sunxi_musb_disable as musb_init_controller never gets re-run, so doing a
full reset leaves things in a bad state where only ep0 still seems to
work, this may be what you were seeing before.
Hi,
do you want me to pick this via u-boot-usb/master ?
No, I've already send a pull-req for them via u-boot-sunxi/master and they
are already merged :)
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] sunxi: musb: Fix usb reset handling
On Sunday, June 14, 2015 at 12:40:11 PM, Hans de Goede wrote:
Hi Ian, Paul,
Here is a patch to fix the problems where most usb devices will no longer
work after a usb reset , when connected to the otg controller in host
mode + a related cleanup patch.
Ian I would like to send out a PR with these 2 as fixed for v2015.07, can
you review them please? Note I've not tested this with the otg in gadget
mode, but we do not have gadget mode enabled by default anywhere atm, so
I still consider this suitable as a bugfix for v2015.07.
Paul, can you test these with gadget mode? Specifically if they help the
problem you were seeing when switching roles?
Also this bit from the kernel code for the sunxi glue may be relevant
to your problems:
if ((musb-int_usb MUSB_INTR_RESET) !is_host_active(musb)) {
/* ep0 FADDR must be 0 when (re)entering peripheral mode */
musb_ep_select(musb-mregs, 0);
musb_writeb(musb-mregs, MUSB_FADDR, 0);
}
This is from the interrupt handler in the sunxi-musb glue in the kernel,
maybe we can do the same, and/or maybe we need to do:
/* ep0 FADDR must be 0 when (re)entering peripheral mode */
musb_ep_select(musb-mregs, 0);
musb_writeb(musb-mregs, MUSB_FADDR, 0);
From sunxi_musb_disable?
From my experience sofar we should avoid doing a full reset from musb_stop
/ sunxi_musb_disable as musb_init_controller never gets re-run, so doing a
full reset leaves things in a bad state where only ep0 still seems to
work, this may be what you were seeing before.
Hi,
do you want me to pick this via u-boot-usb/master ?
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 0/2] usb: 2 keyboard fixes for v2015.07
On Thursday, June 18, 2015 at 10:34:32 PM, Hans de Goede wrote: Hi Marek, Hi Hans, While working on enabling the musb device-model support on more sunxi boards, I noticed a problem with usb-keyboards when plugged into an usb-2 hub and thus connected via the ehci code. In the scenario of a usb-kbd connected to an ehci controller, combined with using CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE (*), an ehci code bug triggers which causes every other usb interrupt packet to get lost due to a data toggle mismatch. We've had this bug for a long time, loosing the key release packets most of the time, which did not matter, until my recent usb-kbd keyrepeat changes. The first patch in this series fixes this, the second patch is a better safe then sorry patch I wrote while working on this. Can you please queue both of these up for merging into v2015.07 ? Applied both, 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 v2] usb.h: Always declare usb function prototypes
On Wednesday, June 10, 2015 at 05:04:04 PM, Hans de Goede wrote: There is no harm in declaring the function prototypes even if nothing implements them, and when CONFIG_DM_USB=y the various usb functions are available regardless of any controller drivers being enabled. This fixes compile warnings due to missing prototypes on ARCHs where the ARCH Kconfig always enables CONFIG_DM_USB and various usb drivers. One could argue that in the case of no controllers CONFIG_DM_USB should not be set, but this problem is typically seen during bringup of boards which do actually have usb controllers. Signed-off-by: Hans de Goede hdego...@redhat.com Applied, thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] Add support for Vybrid VF610-based PCM052
This patch series introduces the vf610-based PCM052 target after a few fixes to the vf610 code. As indicated in the last patch in the series, there is a bug in the FEC whereby it wrongly reports having sent out a packet. This bug does not seem specific to PCM052, and it also seems to appear in the TimeSys U-Boot deliveries and also in Linux, with varying frequencies. NOTE: this series is not checkpatch-clean. It has: - 51 line over 80 characters warnings. These lines are in a block for which the line lenght limit was obviously waived. arch/arm/include/asm/arch-vf610/iomux-vf610.h has 5 of these; board/phytec/pcm052/pcm052.c has the remaining 50. - 1 please write a paragraph that describes the config symbol fully warning for arch/arm/Kconfig. There are no such descriptions for any target in this file. - 1 need consistent spacing around '|' (ctx:WxV) error in board/phytec/pcm052/pcm052.c at line 98. It seems spurious to me, as this construct has the exact same spacing as all others in the file. Albert ARIBAUD (3ADEV) (5): net: fec_mxc: remove useless struct nbuf vf610: refactor DDRMC code i2c: fix vf610 support tools: mkimage: fix imximage header size vf610: add support for Phytec PCM052 arch/arm/Kconfig | 5 + arch/arm/imx-common/ddrmc-vf610.c | 239 +++- arch/arm/include/asm/arch-vf610/crm_regs.h| 3 + arch/arm/include/asm/arch-vf610/ddrmc-vf610.h | 60 +-- arch/arm/include/asm/arch-vf610/imx-regs.h| 3 + arch/arm/include/asm/arch-vf610/iomux-vf610.h | 11 +- arch/arm/include/asm/imx-common/iomux-v3.h| 2 + board/freescale/vf610twr/vf610twr.c | 181 ++--- board/phytec/pcm052/Kconfig | 15 + board/phytec/pcm052/MAINTAINERS | 6 + board/phytec/pcm052/Makefile | 7 + board/phytec/pcm052/imximage.cfg | 17 + board/phytec/pcm052/pcm052.c | 530 ++ board/toradex/colibri_vf/colibri_vf.c | 169 ++-- configs/pcm052_defconfig | 6 + drivers/i2c/mxc_i2c.c | 3 +- drivers/net/fec_mxc.c | 20 +- include/configs/pcm052.h | 234 tools/imximage.h | 1 + 19 files changed, 1155 insertions(+), 357 deletions(-) create mode 100644 board/phytec/pcm052/Kconfig create mode 100644 board/phytec/pcm052/MAINTAINERS create mode 100644 board/phytec/pcm052/Makefile create mode 100644 board/phytec/pcm052/imximage.cfg create mode 100644 board/phytec/pcm052/pcm052.c create mode 100644 configs/pcm052_defconfig create mode 100644 include/configs/pcm052.h -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] vf610: add support for Phytec PCM052
Devices supported are: - NFC (NAND FLASH) - MMC - QSPI (SPI NOR FLASH) - I2C (only bus 2) - I2C RTC - I2C EEPROM - FEC NOTES: 1. The NAND partitioning is different from the TimeSys U-Boot deliveries' for the following reasons: - mainline U-Boot is bigger than TimeSys', even though it now builds for Thumb state, which forces the bootloader area size to increase by 128KB; - The redundant environment definition in the TimeSys deliveries is erroneous, as both environments are in the same Flash sector. Here each environment gest its own sector, which increases the size needed for the environments by 128KB; - The kernel area was consequently reduced by 256KB, and the rootfs area left unchanged (depending on the actual kernel size, the kernel and rootfs area sizes may need to change again in the future). 2. The FEC presents a bug whereby it will indicate a packet as sent but will not actually have sent it. Caches are not the cause. Erratum e6358 is not the cause, and implementing this erratum's workaround does not fix the bug. The FEC's observable state is strictly the same (and correct) whether the packet was actually sent or not, i.e., there is no way to detect a bug occurrence, apart from the higher layer failure (e.g. TFTP timeout). At this point I suspect this to be a silicon bug. Patch-series: 1 Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr --- arch/arm/Kconfig | 5 + board/phytec/pcm052/Kconfig | 15 ++ board/phytec/pcm052/MAINTAINERS | 6 + board/phytec/pcm052/Makefile | 7 + board/phytec/pcm052/imximage.cfg | 17 ++ board/phytec/pcm052/pcm052.c | 530 +++ configs/pcm052_defconfig | 6 + include/configs/pcm052.h | 234 + 8 files changed, 820 insertions(+) create mode 100644 board/phytec/pcm052/Kconfig create mode 100644 board/phytec/pcm052/MAINTAINERS create mode 100644 board/phytec/pcm052/Makefile create mode 100644 board/phytec/pcm052/imximage.cfg create mode 100644 board/phytec/pcm052/pcm052.c create mode 100644 configs/pcm052_defconfig create mode 100644 include/configs/pcm052.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ac86518..27a5a04 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -661,6 +661,10 @@ config TARGET_COLIBRI_VF bool Support Colibri VF50/61 select CPU_V7 +config TARGET_PCM052 + bool Support pcm-052 + select CPU_V7 + config ARCH_ZYNQ bool Xilinx Zynq Platform select CPU_V7 @@ -936,6 +940,7 @@ source board/palmld/Kconfig source board/palmtc/Kconfig source board/palmtreo680/Kconfig source board/phytec/pcm051/Kconfig +source board/phytec/pcm052/Kconfig source board/ppcag/bg0900/Kconfig source board/pxa255_idp/Kconfig source board/samsung/smdk2410/Kconfig diff --git a/board/phytec/pcm052/Kconfig b/board/phytec/pcm052/Kconfig new file mode 100644 index 000..d67a69a --- /dev/null +++ b/board/phytec/pcm052/Kconfig @@ -0,0 +1,15 @@ +if TARGET_PCM052 + +config SYS_BOARD + default pcm052 + +config SYS_VENDOR + default phytec + +config SYS_SOC + default vf610 + +config SYS_CONFIG_NAME + default pcm052 + +endif diff --git a/board/phytec/pcm052/MAINTAINERS b/board/phytec/pcm052/MAINTAINERS new file mode 100644 index 000..a877436 --- /dev/null +++ b/board/phytec/pcm052/MAINTAINERS @@ -0,0 +1,6 @@ +PCM052 BOARD +M: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr +S: Maintained +F: board/phytec/pcm052/ +F: include/configs/pcm052.h +F: configs/pcm052_defconfig diff --git a/board/phytec/pcm052/Makefile b/board/phytec/pcm052/Makefile new file mode 100644 index 000..144f4e7 --- /dev/null +++ b/board/phytec/pcm052/Makefile @@ -0,0 +1,7 @@ +# +# Copyright 2013 Freescale Semiconductor, Inc. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := pcm052.o diff --git a/board/phytec/pcm052/imximage.cfg b/board/phytec/pcm052/imximage.cfg new file mode 100644 index 000..f5a9747 --- /dev/null +++ b/board/phytec/pcm052/imximage.cfg @@ -0,0 +1,17 @@ +/* + * Copyright 2015 3ADEV http://www.3adev.com + * + * SPDX-License-Identifier:GPL-2.0+ + * + * Refer docs/README.imxmage for more details about how-to configure + * and create imximage boot image + * + * The syntax is taken as close as possible with the kwbimage + */ +#include asm/imx-common/imximage.cfg + +/* image version */ +IMAGE_VERSION 2 + +/* Boot Offset 0x400, valid for both SD and NAND boot */ +BOOT_OFFSETFLASH_OFFSET_STANDARD diff --git a/board/phytec/pcm052/pcm052.c b/board/phytec/pcm052/pcm052.c new file mode 100644 index 000..0607f1c --- /dev/null +++ b/board/phytec/pcm052/pcm052.c @@ -0,0 +1,530 @@ +/* + * Copyright 2013 Freescale Semiconductor, Inc. + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include common.h +#include asm/io.h +#include asm/arch/imx-regs.h +#include asm/arch/iomux-vf610.h +#include asm/arch/ddrmc-vf610.h
[U-Boot] [PATCH 4/5] tools: mkimage: fix imximage header size
imximage header size is 4-byte, not 8-byte aligned.
This produces .imx images that a Vybrid cannot boot
on.
Fix by adding a padding field in header.
Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr
---
tools/imximage.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/imximage.h b/tools/imximage.h
index 36fe095..a913329 100644
--- a/tools/imximage.h
+++ b/tools/imximage.h
@@ -129,6 +129,7 @@ typedef struct {
ivt_header_t header;
write_dcd_command_t write_dcd_command;
dcd_addr_data_t addr_data[MAX_HW_CFG_SIZE_V2];
+ uint32_t padding[1]; /* end up on an 8-byte boundary */
} dcd_v2_t;
typedef struct {
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] vf610: refactor DDRMC code
The VF610 DDRMC driver code contains settings which are
board-specific. Move these out to boards so that new boards
can define their own without having to modify the driver.
Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr
---
arch/arm/imx-common/ddrmc-vf610.c | 239 ++
arch/arm/include/asm/arch-vf610/ddrmc-vf610.h | 60 +--
board/freescale/vf610twr/vf610twr.c | 181 +--
board/toradex/colibri_vf/colibri_vf.c | 169 +-
4 files changed, 312 insertions(+), 337 deletions(-)
diff --git a/arch/arm/imx-common/ddrmc-vf610.c
b/arch/arm/imx-common/ddrmc-vf610.c
index e462631..44b9a0f 100644
--- a/arch/arm/imx-common/ddrmc-vf610.c
+++ b/arch/arm/imx-common/ddrmc-vf610.c
@@ -12,9 +12,9 @@
#include asm/arch/iomux-vf610.h
#include asm/arch/ddrmc-vf610.h
-void ddrmc_setup_iomux(void)
+void ddrmc_setup_iomux(const iomux_v3_cfg_t *pads, int pads_count)
{
- static const iomux_v3_cfg_t ddr_pads[] = {
+ static const iomux_v3_cfg_t default_pads[] = {
VF610_PAD_DDR_A15__DDR_A_15,
VF610_PAD_DDR_A14__DDR_A_14,
VF610_PAD_DDR_A13__DDR_A_13,
@@ -65,212 +65,77 @@ void ddrmc_setup_iomux(void)
VF610_PAD_DDR_RESETB,
};
- imx_iomux_v3_setup_multiple_pads(ddr_pads, ARRAY_SIZE(ddr_pads));
-}
+ if ((pads == NULL) || (pads_count == 0)) {
+ pads = default_pads;
+ pads_count = ARRAY_SIZE(default_pads);
+ }
-void ddrmc_phy_init(void)
-{
- struct ddrmr_regs *ddrmr = (struct ddrmr_regs *)DDR_BASE_ADDR;
+ imx_iomux_v3_setup_multiple_pads(pads, pads_count);
+}
- writel(DDRMC_PHY_DQ_TIMING, ddrmr-phy[0]);
- writel(DDRMC_PHY_DQ_TIMING, ddrmr-phy[16]);
- writel(DDRMC_PHY_DQ_TIMING, ddrmr-phy[32]);
+static struct ddrmc_reg_setting default_phy_settings[] = {
+ { DDRMC_PHY_DQ_TIMING, 0 },
+ { DDRMC_PHY_DQ_TIMING, 16 },
+ { DDRMC_PHY_DQ_TIMING, 32 },
- writel(DDRMC_PHY_DQS_TIMING, ddrmr-phy[1]);
- writel(DDRMC_PHY_DQS_TIMING, ddrmr-phy[17]);
+ { DDRMC_PHY_DQS_TIMING, 1 },
+ { DDRMC_PHY_DQS_TIMING, 17 },
- writel(DDRMC_PHY_CTRL, ddrmr-phy[2]);
- writel(DDRMC_PHY_CTRL, ddrmr-phy[18]);
- writel(DDRMC_PHY_CTRL, ddrmr-phy[34]);
+ { DDRMC_PHY_CTRL, 2 },
+ { DDRMC_PHY_CTRL, 18 },
+ { DDRMC_PHY_CTRL, 34 },
- writel(DDRMC_PHY_MASTER_CTRL, ddrmr-phy[3]);
- writel(DDRMC_PHY_MASTER_CTRL, ddrmr-phy[19]);
- writel(DDRMC_PHY_MASTER_CTRL, ddrmr-phy[35]);
+ { DDRMC_PHY_MASTER_CTRL, 3 },
+ { DDRMC_PHY_MASTER_CTRL, 19 },
+ { DDRMC_PHY_MASTER_CTRL, 35 },
- writel(DDRMC_PHY_SLAVE_CTRL, ddrmr-phy[4]);
- writel(DDRMC_PHY_SLAVE_CTRL, ddrmr-phy[20]);
- writel(DDRMC_PHY_SLAVE_CTRL, ddrmr-phy[36]);
+ { DDRMC_PHY_SLAVE_CTRL, 4 },
+ { DDRMC_PHY_SLAVE_CTRL, 20 },
+ { DDRMC_PHY_SLAVE_CTRL, 36 },
/* LPDDR2 only parameter */
- writel(DDRMC_PHY_OFF, ddrmr-phy[49]);
+ { DDRMC_PHY_OFF, 49 },
- writel(DDRMC_PHY50_DDR3_MODE |
- DDRMC_PHY50_EN_SW_HALF_CYCLE, ddrmr-phy[50]);
+ { DDRMC_PHY50_DDR3_MODE | DDRMC_PHY50_EN_SW_HALF_CYCLE, 50 },
/* Processor Pad ODT settings */
- writel(DDRMC_PHY_PROC_PAD_ODT, ddrmr-phy[52]);
-}
+ { DDRMC_PHY_PROC_PAD_ODT, 52 },
-static void ddrmc_ctrl_lvl_init(struct ddrmc_lvl_info *lvl)
-{
- struct ddrmr_regs *ddrmr = (struct ddrmr_regs *)DDR_BASE_ADDR;
- u32 cr102 = 0, cr105 = 0, cr106 = 0, cr110 = 0;
+ /* end marker */
+ { 0, -1 }
+};
- if (lvl-wrlvl_reg_en) {
- writel(DDRMC_CR97_WRLVL_EN, ddrmr-cr[97]);
- writel(DDRMC_CR98_WRLVL_DL_0(lvl-wrlvl_dl_0), ddrmr-cr[98]);
- writel(DDRMC_CR99_WRLVL_DL_1(lvl-wrlvl_dl_1), ddrmr-cr[99]);
- }
-
- if (lvl-rdlvl_reg_en) {
- cr102 |= DDRMC_CR102_RDLVL_REG_EN;
- cr105 |= DDRMC_CR105_RDLVL_DL_0(lvl-rdlvl_dl_0);
- cr110 |= DDRMC_CR110_RDLVL_DL_1(lvl-rdlvl_dl_1);
- }
-
- if (lvl-rdlvl_gt_reg_en) {
- cr102 |= DDRMC_CR102_RDLVL_GT_REGEN;
- cr106 |= DDRMC_CR106_RDLVL_GTDL_0(lvl-rdlvl_gt_dl_0);
- cr110 |= DDRMC_CR110_RDLVL_GTDL_1(lvl-rdlvl_gt_dl_1);
- }
-
- writel(cr102, ddrmr-cr[102]);
- writel(cr105, ddrmr-cr[105]);
- writel(cr106, ddrmr-cr[106]);
- writel(cr110, ddrmr-cr[110]);
-}
-
-void ddrmc_ctrl_init_ddr3(struct ddr3_jedec_timings const *timings,
- struct ddrmc_lvl_info *lvl,
- int col_diff, int row_diff)
+void ddrmc_ctrl_init_ddr3(struct ddrmc_reg_setting const *cr_settings,
+ struct ddrmc_reg_setting const *phy_settings)
{
struct ddrmr_regs *ddrmr = (struct ddrmr_regs *)DDR_BASE_ADDR;
+ struct
Re: [U-Boot] [PATCH] arm, imx: fix spl compile for mxs boards
...I do not understand why I can compile clean (u-boot-imx): ./tools/buildman/buildman mx28evk boards.cfg is up to date. Nothing to do. Building current source for 4 boards (4 threads, 2 jobs per thread) 400 /4 0:00:48 : mx28evk_auart_console And all mxb boards are compiled clean, too. It appears you can compile clean because that defconfig (mx28evk_auart_console) doesnt fully enable the serial output. You still need to define CONFIG_SPL_SERIAL_SUPPORT somewhere or else mxs_spl_console_init() just optimises away. When I define this in configs/mxs.h I get the build error. Can you re-consider applying this patch given the above? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] i2c: fix vf610 support
Add support in mxc_i2c driver, iomux_v3 and vf610 architecture for the four
I2C instances available in VF610.
Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr
---
arch/arm/include/asm/arch-vf610/crm_regs.h| 3 +++
arch/arm/include/asm/arch-vf610/imx-regs.h| 3 +++
arch/arm/include/asm/arch-vf610/iomux-vf610.h | 11 +++
arch/arm/include/asm/imx-common/iomux-v3.h| 2 ++
drivers/i2c/mxc_i2c.c | 3 ++-
5 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index fdb45e9..a46e396 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -207,6 +207,7 @@ struct anadig_reg {
#define CCM_CCGR4_CCM_CTRL_MASK(0x3 22)
#define CCM_CCGR4_GPC_CTRL_MASK(0x3 24)
#define CCM_CCGR4_I2C0_CTRL_MASK (0x3 12)
+#define CCM_CCGR4_I2C1_CTRL_MASK (0x3 14)
#define CCM_CCGR6_OCOTP_CTRL_MASK (0x3 10)
#define CCM_CCGR6_DSPI2_CTRL_MASK (0x3 24)
#define CCM_CCGR6_DSPI3_CTRL_MASK (0x3 26)
@@ -216,6 +217,8 @@ struct anadig_reg {
#define CCM_CCGR9_FEC0_CTRL_MASK 0x3
#define CCM_CCGR9_FEC1_CTRL_MASK (0x3 2)
#define CCM_CCGR10_NFC_CTRL_MASK 0x3
+#define CCM_CCGR10_I2C2_CTRL_MASK (0x3 12)
+#define CCM_CCGR10_I2C3_CTRL_MASK (0x3 14)
#define ANADIG_PLL7_CTRL_BYPASS (1 16)
#define ANADIG_PLL7_CTRL_ENABLE (1 13)
diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h
b/arch/arm/include/asm/arch-vf610/imx-regs.h
index 7df3b1e..4366985 100644
--- a/arch/arm/include/asm/arch-vf610/imx-regs.h
+++ b/arch/arm/include/asm/arch-vf610/imx-regs.h
@@ -75,6 +75,9 @@
#define ESAI_FIFO_BASE_ADDR(AIPS0_BASE_ADDR + 0x00063000)
#define WDOG_BASE_ADDR (AIPS0_BASE_ADDR + 0x00065000)
#define I2C1_BASE_ADDR (AIPS0_BASE_ADDR + 0x00066000)
+#define I2C2_BASE_ADDR (AIPS0_BASE_ADDR + 0x00067000)
+#define I2C3_BASE_ADDR (AIPS0_BASE_ADDR + 0x000E6000)
+#define I2C4_BASE_ADDR (AIPS0_BASE_ADDR + 0x000E7000)
#define WKUP_BASE_ADDR (AIPS0_BASE_ADDR + 0x0006A000)
#define CCM_BASE_ADDR (AIPS0_BASE_ADDR + 0x0006B000)
#define GPC_BASE_ADDR (AIPS0_BASE_ADDR + 0x0006C000)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index 019307b..0e2bd53 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -20,7 +20,8 @@
#define VF610_DDR_PAD_CTRL_1 (PAD_CTL_DSE_25ohm | \
PAD_CTL_INPUT_DIFFERENTIAL)
#define VF610_I2C_PAD_CTRL (PAD_CTL_PUS_47K_UP | PAD_CTL_DSE_50ohm | \
- PAD_CTL_SPEED_HIGH | PAD_CTL_OBE_IBE_ENABLE)
+ PAD_CTL_SPEED_HIGH | PAD_CTL_ODE | \
+ PAD_CTL_OBE_IBE_ENABLE)
#define VF610_NFC_IO_PAD_CTRL (PAD_CTL_SPEED_MED | PAD_CTL_SRE | \
PAD_CTL_DSE_50ohm | PAD_CTL_PUS_47K_UP | \
PAD_CTL_OBE_IBE_ENABLE)
@@ -110,6 +111,8 @@ enum {
VF610_PAD_PTA29__ESDHC1_DAT3= IOMUX_PAD(0x004c, 0x004c, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
VF610_PAD_PTB14__I2C0_SCL = IOMUX_PAD(0x0090, 0x0090, 2,
0x033c, 1, VF610_I2C_PAD_CTRL),
VF610_PAD_PTB15__I2C0_SDA = IOMUX_PAD(0x0094, 0x0094, 2,
0x0340, 1, VF610_I2C_PAD_CTRL),
+ VF610_PAD_PTA22__I2C2_SCL = IOMUX_PAD(0x0030, 0x0030, 6,
0x034c, 0, VF610_I2C_PAD_CTRL),
+ VF610_PAD_PTA23__I2C2_SDA = IOMUX_PAD(0x0034, 0x0034, 6,
0x0350, 0, VF610_I2C_PAD_CTRL),
VF610_PAD_PTD31__NF_IO15= IOMUX_PAD(0x00fc, 0x00fc, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
VF610_PAD_PTD31__GPIO_63= IOMUX_PAD(0x00fc, 0x00fc, 0,
__NA_, 0, VF610_GPIO_PAD_CTRL),
VF610_PAD_PTD30__NF_IO14= IOMUX_PAD(0x0100, 0x0100, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
@@ -146,10 +149,10 @@ enum {
VF610_PAD_PTD12__GPIO_91= IOMUX_PAD(0x016c, 0x016c, 0,
__NA_, 0, VF610_GPIO_PAD_CTRL),
VF610_PAD_PTD13__GPIO_92= IOMUX_PAD(0x0170, 0x0170, 0,
__NA_, 0, VF610_GPIO_PAD_CTRL),
VF610_PAD_PTD22__NF_IO6 = IOMUX_PAD(0x0120, 0x0120, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
- VF610_PAD_PTD21__NF_IO5 = IOMUX_PAD(0x0124, 0x0124, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
- VF610_PAD_PTD20__NF_IO4 = IOMUX_PAD(0x0128, 0x0128, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD21__NF_IO5 = IOMUX_PAD(0x0124, 0x0124, 2,
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
+ VF610_PAD_PTD20__NF_IO4 =
[U-Boot] [PATCH 1/5] net: fec_mxc: remove useless struct nbuf
This locally defined struct is actually only used once
and as an opaque type. Remove it for clarity.
Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr
---
drivers/net/fec_mxc.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 9225d37..c5dcbbb 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -67,13 +67,6 @@ DECLARE_GLOBAL_DATA_PTR;
#undef DEBUG
-struct nbuf {
- uint8_t data[1500]; /** actual data */
- int length; /** actual length */
- int used; /** buffer in use or not */
- uint8_t head[16]; /** MAC header(6 + 6 + 2) + 2(aligned) */
-};
-
#ifdef CONFIG_FEC_MXC_SWAP_PACKET
static void swap_packet(uint32_t *packet, int length)
{
@@ -775,7 +768,6 @@ static int fec_recv(struct eth_device *dev)
struct fec_bd *rbd = fec-rbd_base[fec-rbd_index];
unsigned long ievent;
int frame_length, len = 0;
- struct nbuf *frame;
uint16_t bd_status;
uint32_t addr, size, end;
int i;
@@ -835,12 +827,11 @@ static int fec_recv(struct eth_device *dev)
/*
* Get buffer address and size
*/
- frame = (struct nbuf *)readl(rbd-data_pointer);
+ addr = readl(rbd-data_pointer);
frame_length = readw(rbd-data_length) - 4;
/*
* Invalidate data cache over the buffer
*/
- addr = (uint32_t)frame;
end = roundup(addr + frame_length, ARCH_DMA_MINALIGN);
addr = ~(ARCH_DMA_MINALIGN - 1);
invalidate_dcache_range(addr, end);
@@ -849,16 +840,15 @@ static int fec_recv(struct eth_device *dev)
* Fill the buffer and pass it to upper layers
*/
#ifdef CONFIG_FEC_MXC_SWAP_PACKET
- swap_packet((uint32_t *)frame-data, frame_length);
+ swap_packet((uint32_t *)addr, frame_length);
#endif
- memcpy(buff, frame-data, frame_length);
+ memcpy(buff, (char *)addr, frame_length);
net_process_received_packet(buff, frame_length);
len = frame_length;
} else {
if (bd_status FEC_RBD_ERR)
- printf(error frame: 0x%08lx 0x%08x\n,
- (ulong)rbd-data_pointer,
- bd_status);
+ printf(error frame: 0x%08x 0x%08x\n,
+ addr, bd_status);
}
/*
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] arm: ls102xa: Enable Driver Model SPI for ls1021atwr
On 6/19/2015 3:34 PM, Jagan Teki wrote: On 18 June 2015 at 12:24, Jagan Teki jt...@openedev.com wrote: On 18 June 2015 at 07:50, Wang Haikun haikun.w...@freescale.com wrote: On 6/17/2015 8:30 PM, Simon Glass wrote: Hi, On 17 June 2015 at 03:36, Bin Meng bmeng...@gmail.com wrote: Hi Haikun, On Mon, May 18, 2015 at 9:25 PM, Haikun Wang haikun.w...@freescale.com wrote: From: Haikun Wang haikun.w...@freescale.com Enable Driver Model SPI for ls1021atwr board. DSPI and QSPI only be enabled when boot from QSPI. DSPI and QSPI are compatible under Driver Model SPI. Signed-off-by: Haikun Wang haikun.w...@freescale.com Change-Id: I6342807da7725ae8b678952117c8758c75a61d3d Where is this commit id? I couldn't see it on git log Hi Jagan, It is not a git commit ID, it is a code review task ID of gerrit in fact. I'm sorry again for forgetting remove it when submit patch. Best regards, Wang Haikun Reviewed-on: http://git.am.freescale.net:8181/33447 Best regards, Wang Haikun Is this URL Freescale internal? I cannot access it. Looks like it. BTW patman will remove these Gerrit tags automatically. Yes, it is our internal URL. I forget to remove it. It couldn't be better if it will be removed automatically. I will remove if something not remove automatically. Anyone have any comments on these patch-set, I'm planning to take these. https://patchwork.ozlabs.org/patch/473391/ https://patchwork.ozlabs.org/patch/473392/ https://patchwork.ozlabs.org/patch/473393/ https://patchwork.ozlabs.org/patch/473394/ Tested-by: Review Code-CDREVIEW cdrev...@freescale.com Reviewed-by: Prabhakar Kushwaha prabha...@freescale.com --- Changes in v3: - IS_ENABLED(CONFIG_XXX) is only work with configure option in Kconfig, and DM core code use IS_ENABLED(), so configure option in head file can't work, so remove CONFIG_OF_CONTROL CONFIG_OF_SEPARATE CONFIG_DM CONFIG_DM_SPI Changes in v2: - Move all changes inside of CONFIG_QSPI_BOOT Changes in v1: None include/configs/ls1021atwr.h | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 729205f..13e3aa4 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -229,16 +229,22 @@ #define CONFIG_CMD_FAT #define CONFIG_DOS_PARTITION -/* QSPI */ +/* SPI */ #ifdef CONFIG_QSPI_BOOT +/* QSPI */ #define CONFIG_FSL_QSPI #define QSPI0_AMBA_BASE0x4000 #define FSL_QSPI_FLASH_SIZE(1 24) #define FSL_QSPI_FLASH_NUM 2 +#define CONFIG_SPI_FLASH_STMICRO + +/* DM SPI */ +#if defined(CONFIG_FSL_DSPI) || defined(CONFIG_FSL_QSPI) #define CONFIG_CMD_SF +#define CONFIG_DM_SPI_FLASH #define CONFIG_SPI_FLASH -#define CONFIG_SPI_FLASH_STMICRO +#endif #endif /* thanks! -- Jagan | openedev. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] sunxi: musb: Fix usb reset handling
Le mercredi 17 juin 2015 à 15:39 +0200, Hans de Goede a écrit : Hi, On 15-06-15 21:21, Paul Kocialkowski wrote: Le dimanche 14 juin 2015 à 12:40 +0200, Hans de Goede a écrit : Hi Ian, Paul, Here is a patch to fix the problems where most usb devices will no longer work after a usb reset , when connected to the otg controller in host mode + a related cleanup patch. This works fine for an USB storage device and an USB2 keyboard but does not work with an USB1 keyboard, with error: sunxi# usb reset resetting USB... USB0: scanning bus 0 for devices... USB device descriptor short read (expected 8, got 0) No USB Device found Hmm, did you test my sunxi-wip branch perhaps? This bug does exist there, but it is the result of me refactoring things so that the musb code can use the device-model when build in host mode, which will allow enabling both the otg port in host mode and regular usb hosts in a single build, which is esp. useful for boards which have the otg hooked up in host-only mode (e.g. connected to an usb-a receptacle, or usb - sata bridge). This is nice, thanks a lot for all your work! I did however test on top of the regular U-Boot tree. I'll try again in a few days to see if it still happens. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] ARM: DRA72x: fix io delay calibration for ethernet
Ethernet on DRA72x EVM is not working as the io delay calibration
value is not correct. Fixing this with the correct values and
verified this on DRA72x EVM with tftp file transfer
Cc: Nishanth Menon n...@ti.com
Cc: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
board/ti/dra7xx/mux_data.h | 48 +++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index c9301a5..0ca3c51 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -156,30 +156,30 @@ const struct pad_conf_entry early_padconf[] = {
#ifdef CONFIG_IODELAY_RECALIBRATION
const struct iodelay_cfg_entry iodelay_cfg_array[] = {
- {0x6F0, 480, 0}, /* RGMMI0_RXC_IN */
- {0x6FC, 111, 1641}, /* RGMMI0_RXCTL_IN */
- {0x708, 272, 1116}, /* RGMMI0_RXD0_IN */
- {0x714, 243, 1260}, /* RGMMI0_RXD1_IN */
- {0x720, 0, 1614}, /* RGMMI0_RXD2_IN */
- {0x72C, 105, 1673}, /* RGMMI0_RXD3_IN */
- {0x740, 531, 120}, /* RGMMI0_TXC_OUT */
- {0x74C, 11, 60}, /* RGMMI0_TXCTL_OUT */
- {0x758, 7, 120}, /* RGMMI0_TXD0_OUT */
- {0x764, 0, 0}, /* RGMMI0_TXD1_OUT */
- {0x770, 276, 120}, /* RGMMI0_TXD2_OUT */
- {0x77C, 440, 120}, /* RGMMI0_TXD3_OUT */
- {0xAB0, 702, 0}, /* CFG_VIN2A_D18_IN */
- {0xABC, 136, 976}, /* CFG_VIN2A_D19_IN */
- {0xAD4, 210, 1357}, /* CFG_VIN2A_D20_IN */
- {0xAE0, 189, 1462}, /* CFG_VIN2A_D21_IN */
- {0xAEC, 232, 1278}, /* CFG_VIN2A_D22_IN */
- {0xAF8, 0, 1397}, /* CFG_VIN2A_D23_IN */
- {0xA70, 1551, 115}, /* CFG_VIN2A_D12_OUT */
- {0xA7C, 816, 0}, /* CFG_VIN2A_D13_OUT */
- {0xA88, 876, 0}, /* CFG_VIN2A_D14_OUT */
- {0xA94, 312, 0}, /* CFG_VIN2A_D15_OUT */
- {0xAA0, 58, 0}, /* CFG_VIN2A_D16_OUT */
- {0xAAC, 0, 0}, /* CFG_VIN2A_D17_OUT */
+ {0x6F0, 359, 0}, /* RGMMI0_RXC_IN */
+ {0x6FC, 129, 1896}, /* RGMMI0_RXCTL_IN */
+ {0x708, 80, 1391}, /* RGMMI0_RXD0_IN */
+ {0x714, 196, 1522}, /* RGMMI0_RXD1_IN */
+ {0x720, 40, 1860}, /* RGMMI0_RXD2_IN */
+ {0x72C, 0, 1956}, /* RGMMI0_RXD3_IN */
+ {0x740, 0, 220}, /* RGMMI0_TXC_OUT */
+ {0x74C, 1820, 180}, /* RGMMI0_TXCTL_OUT */
+ {0x758, 1740, 440}, /* RGMMI0_TXD0_OUT */
+ {0x764, 1740, 240}, /* RGMMI0_TXD1_OUT */
+ {0x770, 1680, 380}, /* RGMMI0_TXD2_OUT */
+ {0x77C, 1740, 440}, /* RGMMI0_TXD3_OUT */
+ {0xAB0, 596, 0}, /* CFG_VIN2A_D18_IN */
+ {0xABC, 314, 980}, /* CFG_VIN2A_D19_IN */
+ {0xAD4, 241, 1536}, /* CFG_VIN2A_D20_IN */
+ {0xAE0, 103, 1689}, /* CFG_VIN2A_D21_IN */
+ {0xAEC, 161, 1563}, /* CFG_VIN2A_D22_IN */
+ {0xAF8, 0, 1613}, /* CFG_VIN2A_D23_IN */
+ {0xA70, 0, 200}, /* CFG_VIN2A_D12_OUT */
+ {0xA7C, 1560, 140}, /* CFG_VIN2A_D13_OUT */
+ {0xA88, 1700, 0}, /* CFG_VIN2A_D14_OUT */
+ {0xA94, 1260, 0}, /* CFG_VIN2A_D15_OUT */
+ {0xAA0, 1400, 0}, /* CFG_VIN2A_D16_OUT */
+ {0xAAC, 1290, 0}, /* CFG_VIN2A_D17_OUT */
};
#endif
--
2.4.2.387.gf86f31a
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ARM: DRA72x: fix io delay calibration for ethernet
On Friday 19 June 2015 04:45 PM, Mugunthan V N wrote:
Ethernet on DRA72x EVM is not working as the io delay calibration
value is not correct. Fixing this with the correct values and
verified this on DRA72x EVM with tftp file transfer
Yeah, I missed this. Thanks for the patch.
Tested this on DRA72-evm.
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Thanks and regards,
Lokesh
Cc: Nishanth Menon n...@ti.com
Cc: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
board/ti/dra7xx/mux_data.h | 48
+++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index c9301a5..0ca3c51 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -156,30 +156,30 @@ const struct pad_conf_entry early_padconf[] = {
#ifdef CONFIG_IODELAY_RECALIBRATION
const struct iodelay_cfg_entry iodelay_cfg_array[] = {
- {0x6F0, 480, 0}, /* RGMMI0_RXC_IN */
- {0x6FC, 111, 1641}, /* RGMMI0_RXCTL_IN */
- {0x708, 272, 1116}, /* RGMMI0_RXD0_IN */
- {0x714, 243, 1260}, /* RGMMI0_RXD1_IN */
- {0x720, 0, 1614}, /* RGMMI0_RXD2_IN */
- {0x72C, 105, 1673}, /* RGMMI0_RXD3_IN */
- {0x740, 531, 120}, /* RGMMI0_TXC_OUT */
- {0x74C, 11, 60}, /* RGMMI0_TXCTL_OUT */
- {0x758, 7, 120}, /* RGMMI0_TXD0_OUT */
- {0x764, 0, 0}, /* RGMMI0_TXD1_OUT */
- {0x770, 276, 120}, /* RGMMI0_TXD2_OUT */
- {0x77C, 440, 120}, /* RGMMI0_TXD3_OUT */
- {0xAB0, 702, 0}, /* CFG_VIN2A_D18_IN */
- {0xABC, 136, 976}, /* CFG_VIN2A_D19_IN */
- {0xAD4, 210, 1357}, /* CFG_VIN2A_D20_IN */
- {0xAE0, 189, 1462}, /* CFG_VIN2A_D21_IN */
- {0xAEC, 232, 1278}, /* CFG_VIN2A_D22_IN */
- {0xAF8, 0, 1397}, /* CFG_VIN2A_D23_IN */
- {0xA70, 1551, 115}, /* CFG_VIN2A_D12_OUT */
- {0xA7C, 816, 0}, /* CFG_VIN2A_D13_OUT */
- {0xA88, 876, 0}, /* CFG_VIN2A_D14_OUT */
- {0xA94, 312, 0}, /* CFG_VIN2A_D15_OUT */
- {0xAA0, 58, 0}, /* CFG_VIN2A_D16_OUT */
- {0xAAC, 0, 0}, /* CFG_VIN2A_D17_OUT */
+ {0x6F0, 359, 0}, /* RGMMI0_RXC_IN */
+ {0x6FC, 129, 1896}, /* RGMMI0_RXCTL_IN */
+ {0x708, 80, 1391}, /* RGMMI0_RXD0_IN */
+ {0x714, 196, 1522}, /* RGMMI0_RXD1_IN */
+ {0x720, 40, 1860}, /* RGMMI0_RXD2_IN */
+ {0x72C, 0, 1956}, /* RGMMI0_RXD3_IN */
+ {0x740, 0, 220}, /* RGMMI0_TXC_OUT */
+ {0x74C, 1820, 180}, /* RGMMI0_TXCTL_OUT */
+ {0x758, 1740, 440}, /* RGMMI0_TXD0_OUT */
+ {0x764, 1740, 240}, /* RGMMI0_TXD1_OUT */
+ {0x770, 1680, 380}, /* RGMMI0_TXD2_OUT */
+ {0x77C, 1740, 440}, /* RGMMI0_TXD3_OUT */
+ {0xAB0, 596, 0}, /* CFG_VIN2A_D18_IN */
+ {0xABC, 314, 980}, /* CFG_VIN2A_D19_IN */
+ {0xAD4, 241, 1536}, /* CFG_VIN2A_D20_IN */
+ {0xAE0, 103, 1689}, /* CFG_VIN2A_D21_IN */
+ {0xAEC, 161, 1563}, /* CFG_VIN2A_D22_IN */
+ {0xAF8, 0, 1613}, /* CFG_VIN2A_D23_IN */
+ {0xA70, 0, 200}, /* CFG_VIN2A_D12_OUT */
+ {0xA7C, 1560, 140}, /* CFG_VIN2A_D13_OUT */
+ {0xA88, 1700, 0}, /* CFG_VIN2A_D14_OUT */
+ {0xA94, 1260, 0}, /* CFG_VIN2A_D15_OUT */
+ {0xAA0, 1400, 0}, /* CFG_VIN2A_D16_OUT */
+ {0xAAC, 1290, 0}, /* CFG_VIN2A_D17_OUT */
};
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] sf: Add support for flag status register on Micron chips
I think you may missed my comment on v2 [1] Just check with master.
If something not works well, will review the same.
[1] https://patchwork.ozlabs.org/patch/469961/
On 25 May 2015 at 09:03, Hou Zhiqiang b48...@freescale.com wrote:
Hi Jagan,
So much long time no comment, could you please apply this patch?
Thanks,
Zhiqiang
-Original Message-
From: Zhiqiang Hou [mailto:b48...@freescale.com]
Sent: 2015年5月11日 16:35
To: u-boot@lists.denx.de; jt...@openedev.com
Cc: Sun York-R58495; Hu Mingkai-B21284; Hou Zhiqiang-B48286; Hu Mingkai-
B21284
Subject: [PATCH V3] sf: Add support for flag status register on Micron
chips
From: Hou Zhiqiang b48...@freescale.com
Enter 3 Byte address mode at first, because it may change to 4 Byte
address mode in kernel driver and not reset to 3 Byte address mode after
reboot.
Add clear flag status register operation that some Micron SPI flash chips
required after reading the flag status register to check some operations
completion.
Signed-off-by: Hou Zhiqiang b48...@freescale.com
Signed-off-by: Mingkai.Hu mingkai...@freescale.com
---
V3:
Generate the patch based on the latest tree git://git.denx.de/u-boot.git.
V2:
Add the operation of enter 3 Byte address mode in probe.
V1:
Based on git://git.denx.de/u-boot.git.
Also can be applied to git://www.denx.de/git/u-boot-mpc85xx.git.
Tested on board T2080QDS and T2080RDB.
drivers/mtd/spi/sf_internal.h | 17
drivers/mtd/spi/sf_ops.c | 64
+--
drivers/mtd/spi/sf_probe.c| 5
3 files changed, 78 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h
b/drivers/mtd/spi/sf_internal.h index 4158e13..24a693e 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -73,6 +73,11 @@ enum {
#define CMD_WRITE_ENABLE 0x06
#define CMD_READ_CONFIG 0x35
#define CMD_FLAG_STATUS 0x70
+#define CMD_CLEAR_FLAG_STATUS0x50
+
+/* Used for Macronix and Winbond flashes */
+#define CMD_ENTER_4B_ADDR 0xB7
+#define CMD_EXIT_4B_ADDR0xE9
/* Read commands */
#define CMD_READ_ARRAY_SLOW 0x03
@@ -96,6 +101,8 @@ enum {
#define STATUS_QEB_WINSPAN (1 1)
#define STATUS_QEB_MXIC (1 6)
#define STATUS_PEC (1 7)
+#define STATUS_PROT (1 1)
+#define STATUS_ERASE (1 5)
/* Flash timeout values */
#define SPI_FLASH_PROG_TIMEOUT (2 * CONFIG_SYS_HZ)
@@ -182,6 +189,12 @@ static inline int spi_flash_cmd_write_disable(struct
spi_flash *flash)
return spi_flash_cmd(flash-spi, CMD_WRITE_DISABLE, NULL, 0); }
+/* Clear flag status register */
+static inline int spi_flash_cmd_clear_flag_status(struct spi_slave
+*spi) {
+ return spi_flash_cmd(spi, CMD_CLEAR_FLAG_STATUS, NULL, 0); }
+
/*
* Send the read status command to the device and wait for the wip
* (write-in-progress) bit to clear itself.
@@ -218,4 +231,8 @@ int spi_flash_read_common(struct spi_flash *flash,
const u8 *cmd, int spi_flash_cmd_read_ops(struct spi_flash *flash, u32
offset,
size_t len, void *data);
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+int spi_flash_cmd_4B_addr_switch(struct spi_flash *flash, int enable);
+#endif
+
#endif /* _SF_INTERNAL_H_ */
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c index
38592f5..1ce14d1 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -93,6 +93,30 @@ int spi_flash_cmd_write_config(struct spi_flash *flash,
u8 wc) } #endif
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+int spi_flash_cmd_4B_addr_switch(struct spi_flash *flash, int enable) {
+ int ret;
+ u8 cmd;
+
+ cmd = enable ? CMD_ENTER_4B_ADDR : CMD_EXIT_4B_ADDR;
+
+ ret = spi_claim_bus(flash-spi);
+ if (ret) {
+ debug(SF: unable to claim SPI bus\n);
+ return ret;
+ }
+
+ ret = spi_flash_cmd_write_enable(flash);
+ if (ret 0) {
+ debug(SF: enabling write failed\n);
+ return ret;
+ }
+
+ return spi_flash_cmd(flash-spi, cmd, NULL, 0); } #endif
+
#ifdef CONFIG_SPI_FLASH_BAR
static int spi_flash_cmd_bankaddr_write(struct spi_flash *flash, u8
bank_sel) { @@ -160,6 +184,7 @@ static int spi_flash_poll_status(struct
spi_slave *spi, unsigned long timeout,
unsigned long timebase;
unsigned long flags = SPI_XFER_BEGIN;
int ret;
+ int out_of_time = 1;
u8 status;
u8 check_status = 0x0;
@@ -182,22 +207,45 @@ static int spi_flash_poll_status(struct spi_slave
*spi, unsigned long timeout,
WATCHDOG_RESET();
ret = spi_xfer(spi, 8, NULL, status, 0);
- if (ret)
+ if (ret) {
+ spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
return -1;
+
Re: [U-Boot] [PATCH 19/22] sunxi: musb: Move musb config and platdata to the sunxi-musb glue
Hi, On 19-06-15 09:43, Ian Campbell wrote: On Wed, 2015-06-17 at 21:34 +0200, Hans de Goede wrote: Move the musb config and platdata to the sunxi-musb glue, which is where it really belongs. This is preparation patch for adding device-model support for the sunxi-musb-host code. Signed-off-by: Hans de Goede hdego...@redhat.com --- arch/arm/include/asm/arch-sunxi/usb_phy.h | 7 +++ board/sunxi/board.c | 28 ++--- drivers/usb/musb-new/sunxi.c | 35 ++- 3 files changed, 34 insertions(+), 36 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/usb_phy.h b/arch/arm/include/asm/arch-sunxi/usb_phy.h index 5a9cacb..17d31b8 100644 --- a/arch/arm/include/asm/arch-sunxi/usb_phy.h +++ b/arch/arm/include/asm/arch-sunxi/usb_phy.h @@ -19,3 +19,10 @@ void sunxi_usb_phy_power_off(int index); int sunxi_usb_phy_vbus_detect(int index); int sunxi_usb_phy_id_detect(int index); void sunxi_usb_phy_enable_squelch_detect(int index, int enable); + +/* Not really phy related, but we have to declare this somewhere ... */ I guess arch/arm/include/asm/arch-sunxi/usbc.h isn't any better? Well we do not have that, and I did not feel it was worth adding yet another .h file for just this one function. With it here or there: Acked-by: Ian Campbell i...@hellion.org.uk Regards, Hans +#if defined(CONFIG_MUSB_HOST) || defined(CONFIG_MUSB_GADGET) +void sunxi_musb_board_init(void); +#else +#define sunxi_musb_board_init() +#endif Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] arm: ls102xa: Enable Driver Model SPI for ls1021atwr
On 19 June 2015 at 13:20, Wang Haikun haikun.w...@freescale.com wrote: On 6/19/2015 3:34 PM, Jagan Teki wrote: On 18 June 2015 at 12:24, Jagan Teki jt...@openedev.com wrote: On 18 June 2015 at 07:50, Wang Haikun haikun.w...@freescale.com wrote: On 6/17/2015 8:30 PM, Simon Glass wrote: Hi, On 17 June 2015 at 03:36, Bin Meng bmeng...@gmail.com wrote: Hi Haikun, On Mon, May 18, 2015 at 9:25 PM, Haikun Wang haikun.w...@freescale.com wrote: From: Haikun Wang haikun.w...@freescale.com Enable Driver Model SPI for ls1021atwr board. DSPI and QSPI only be enabled when boot from QSPI. DSPI and QSPI are compatible under Driver Model SPI. Signed-off-by: Haikun Wang haikun.w...@freescale.com Change-Id: I6342807da7725ae8b678952117c8758c75a61d3d Where is this commit id? I couldn't see it on git log Hi Jagan, It is not a git commit ID, it is a code review task ID of gerrit in fact. I'm sorry again for forgetting remove it when submit patch. Best regards, Wang Haikun Reviewed-on: http://git.am.freescale.net:8181/33447 Best regards, Wang Haikun Is this URL Freescale internal? I cannot access it. Looks like it. BTW patman will remove these Gerrit tags automatically. Yes, it is our internal URL. I forget to remove it. It couldn't be better if it will be removed automatically. I will remove if something not remove automatically. Anyone have any comments on these patch-set, I'm planning to take these. https://patchwork.ozlabs.org/patch/473391/ https://patchwork.ozlabs.org/patch/473392/ https://patchwork.ozlabs.org/patch/473393/ https://patchwork.ozlabs.org/patch/473394/ Applied to u-boot-spi/master thanks! -- Jagan | openedev. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pci: Configure expansion ROM during auto config process
Currently PCI expansion ROM address is assigned by a call to
pciauto_setup_rom() outside of the pci auto config process.
This does not work when expansion ROM is on a device behind
PCI bridge where bridge's memory limit register was already
programmed to a value that does not cover the newly assigned
expansion ROM address. To fix this, we should configure the
ROM address during the auto config process.
Signed-off-by: Bin Meng bmeng...@gmail.com
---
drivers/pci/pci_auto.c | 40 ++--
drivers/pci/pci_rom.c | 5 -
include/pci.h | 9 -
3 files changed, 14 insertions(+), 40 deletions(-)
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index 7c10983..92b4933 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -182,36 +182,24 @@ void pciauto_setup_device(struct pci_controller *hose,
bar_nr++;
}
- pci_hose_write_config_word(hose, dev, PCI_COMMAND, cmdstat);
- pci_hose_write_config_byte(hose, dev, PCI_CACHE_LINE_SIZE,
- CONFIG_SYS_PCI_CACHE_LINE_SIZE);
- pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
-}
-
-int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev)
-{
- pci_addr_t bar_value;
- pci_size_t bar_size;
- u32 bar_response;
- u16 cmdstat = 0;
-
+ /* Configure the expansion ROM address */
pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS, 0xfffe);
pci_hose_read_config_dword(hose, dev, PCI_ROM_ADDRESS, bar_response);
- if (!bar_response)
- return -ENOENT;
-
- bar_size = -(bar_response ~1);
- DEBUGF(PCI Autoconfig: ROM, size=%#x, , bar_size);
- if (pciauto_region_allocate(hose-pci_mem, bar_size, bar_value) == 0) {
- pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS,
- bar_value);
+ if (bar_response) {
+ bar_size = -(bar_response ~1);
+ DEBUGF(PCI Autoconfig: ROM, size=%#x, , bar_size);
+ if (pciauto_region_allocate(mem, bar_size, bar_value) == 0) {
+ pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS,
+ bar_value);
+ }
+ cmdstat |= PCI_COMMAND_MEMORY;
+ DEBUGF(\n);
}
- DEBUGF(\n);
- pci_hose_read_config_word(hose, dev, PCI_COMMAND, cmdstat);
- cmdstat |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
- pci_hose_write_config_word(hose, dev, PCI_COMMAND, cmdstat);
- return 0;
+ pci_hose_write_config_word(hose, dev, PCI_COMMAND, cmdstat);
+ pci_hose_write_config_byte(hose, dev, PCI_CACHE_LINE_SIZE,
+ CONFIG_SYS_PCI_CACHE_LINE_SIZE);
+ pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
}
void pciauto_prescan_setup_bridge(struct pci_controller *hose,
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 37450c8..f364799 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -83,11 +83,6 @@ static int pci_rom_probe(pci_dev_t dev, uint class,
rom_address = CONFIG_X86_OPTION_ROM_ADDR;
#else
- if (pciauto_setup_rom(pci_bus_to_hose(PCI_BUS(dev)), dev)) {
- debug(Cannot find option ROM\n);
- return -ENOENT;
- }
-
pci_read_config_dword(dev, PCI_ROM_ADDRESS, rom_address);
if (rom_address == 0x || rom_address == 0x) {
debug(%s: rom_address=%x\n, __func__, rom_address);
diff --git a/include/pci.h b/include/pci.h
index 07b1e9a..966be97 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -712,15 +712,6 @@ void pci_write_bar32(struct pci_controller *hose,
pci_dev_t dev, int barnum,
u32 pci_read_bar32(struct pci_controller *hose, pci_dev_t dev, int barnum);
/**
- * pciauto_setup_rom() - Set up access to a device ROM
- *
- * @hose: PCI hose to use
- * @dev: PCI device to adjust
- * @return 0 if done, -ve on error
- */
-int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev);
-
-/**
* pci_hose_find_devices() - Find devices by vendor/device ID
*
* @hose: PCI hose to search
--
1.8.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] README: Describe CONFIG_SYS_NO_FLASH
Unlike most configuration options defining this actually disables support for a feature (parallel flash). Eventually the logic behind this should probably be flipped so that '#ifndef CONFIG_SYS_NO_FLASH' becomes '#ifdef CONFIG_HAS_PARALLEL_FLASH' but for now lets document the existing behaviour. Signed-off-by: Chris Packham judge.pack...@gmail.com Reviewed-by: Stefan Roese s...@denx.de --- So this is my attempt to describe (my understanding of) how this option should be used. Any suggestions for improvement are most welcome. Changes in v2: - Dropped RFC - Added review from Stefan README | 13 + 1 file changed, 13 insertions(+) diff --git a/README b/README index 3b406c2..c3fa549 100644 --- a/README +++ b/README @@ -3037,6 +3037,19 @@ CBFS (Coreboot Filesystem) support this is instead controlled by the value of /config/load-environment. +- Parallel Flash support: + CONFIG_SYS_NO_FLASH + + Traditionally U-boot was run on systems with parallel NOR + flash. This option is used to disable support for parallel NOR + flash. This option should be defined if the board does not have + parallel flash. + + If this option is not defined one of the generic flash drivers + (e.g. CONFIG_FLASH_CFI_DRIVER or CONFIG_ST_SMI) must be + selected or the board must provide an implementation of the + flash API (see include/flash.h). + - DataFlash Support: CONFIG_HAS_DATAFLASH -- 2.3.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/22] sunxi: musb: Add id pin support
Hi, On 19-06-15 09:40, Ian Campbell wrote: On Wed, 2015-06-17 at 21:34 +0200, Hans de Goede wrote: When in host mode check if there is a host cable inserted into the otg port by checking the id pin. If there is no host cable return an error to make usb_lowlevel_init() exit early, rather then waiting for 1 second for a device which will never show up. Signed-off-by: Hans de Goede hdego...@redhat.com I guess the defconfig fiddling is here because this is the culmination of these three patches which makes it useful to set this value? Right. In which case: Acked-by: Ian Campbell i...@hellion.org.uk Thanks, Hans Although I'd have been inclined to do it where the Kconfig option was added (ack to that too if you want to move). Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] net: fec_mxc: remove useless struct nbuf
Hi Albert, On Fri, Jun 19, 2015 at 7:18 AM, Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr wrote: This locally defined struct is actually only used once and as an opaque type. Remove it for clarity. Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr --- Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MinnowBoard Max uboot
Hi Thomas, On 19 June 2015 at 09:17, Beaman, Thomas thomas.bea...@xerox.com wrote: Hi Bin, I have tried both suggestions and the kernel boot still hangs in the same place. I have enclosed a snipit from boot that shows the command line. Thanks, Tom -Original Message- From: Bin Meng [mailto:bmeng...@gmail.com] Sent: Thursday, June 18, 2015 9:16 PM To: Beaman, Thomas Cc: Simon Glass; u-boot@lists.denx.de Subject: Re: [U-Boot] MinnowBoard Max uboot Can you try typing 'run ramboot' on the U-Boot shell to load linux kernel? Or below ... Or append acpi=off to the kernel command line manually, to see how it goes. = run ramboot Using RTL8169#0 device TFTP from server 10.40.101.102; our IP address is 10.40.101.244 Filename 'atom_64/kernel'. Load address: 0x1000 Loading: ## 5.6 MiB 3.6 MiB/s done Bytes transferred = 5861312 (596fc0 hex) Using RTL8169#0 device TFTP from server 10.40.101.102; our IP address is 10.40.101.244 Filename 'atom_64/ramdisk'. Load address: 0x2000 Loading: ## 29.1 MiB 3.5 MiB/s done Bytes transferred = 30497951 (1d15c9f hex) Valid Boot Flag Setup Size = 0x3e00 Magic signature found Using boot protocol version 2.0c Linux kernel version 3.10.62-ltsi-WR6.0.0.20_standard (tbeaman@wocket) #1 SMP PREEMPT Wed Jun 17 15:19:47 EDT 2015 Building boot_params at 0x0009 Loading bzImage at address 10 (5845440 bytes) Magic signature found Initial RAM disk at linear address 0x2000, size 30497951 bytes Kernel command line: root=/dev/ram rw ip=10.40.101.244:10.40.101.102::255.255.255.0:x86:eth0:off console=ttyS0,115200 acpi=off ramdisk_size=30 Starting kernel ... I'll see if I can repeat this. I recall that last time I tested it it appeared to hang, but in fact the machine was running (just without a Linux console). Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] vf610: refactor DDRMC code
Hi Albert,
On 19.06.2015 14:18, Albert ARIBAUD (3ADEV) wrote:
The VF610 DDRMC driver code contains settings which are
board-specific. Move these out to boards so that new boards
can define their own without having to modify the driver.
Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr
---
arch/arm/imx-common/ddrmc-vf610.c | 239
++
arch/arm/include/asm/arch-vf610/ddrmc-vf610.h | 60 +--
board/freescale/vf610twr/vf610twr.c | 181 +--
board/toradex/colibri_vf/colibri_vf.c | 169 +-
4 files changed, 312 insertions(+), 337 deletions(-)
So this goes basically back to setting all DDR registers directly from
boards? What we tried to do here is to factor out the memory chip
specific data (JEDEC). The idea behind this is it would make it simpler
to add new RAM timings if a new RAM vendor is used on a different board
revision... With your changes it will be unnecessarily hard to add just
a new RAM timing for a new board revision...
--
Stefan
diff --git a/arch/arm/imx-common/ddrmc-vf610.c
b/arch/arm/imx-common/ddrmc-vf610.c
index e462631..44b9a0f 100644
--- a/arch/arm/imx-common/ddrmc-vf610.c
+++ b/arch/arm/imx-common/ddrmc-vf610.c
@@ -12,9 +12,9 @@
#include asm/arch/iomux-vf610.h
#include asm/arch/ddrmc-vf610.h
-void ddrmc_setup_iomux(void)
+void ddrmc_setup_iomux(const iomux_v3_cfg_t *pads, int pads_count)
{
- static const iomux_v3_cfg_t ddr_pads[] = {
+ static const iomux_v3_cfg_t default_pads[] = {
VF610_PAD_DDR_A15__DDR_A_15,
VF610_PAD_DDR_A14__DDR_A_14,
VF610_PAD_DDR_A13__DDR_A_13,
@@ -65,212 +65,77 @@ void ddrmc_setup_iomux(void)
VF610_PAD_DDR_RESETB,
};
- imx_iomux_v3_setup_multiple_pads(ddr_pads, ARRAY_SIZE(ddr_pads));
-}
+ if ((pads == NULL) || (pads_count == 0)) {
+ pads = default_pads;
+ pads_count = ARRAY_SIZE(default_pads);
+ }
-void ddrmc_phy_init(void)
-{
- struct ddrmr_regs *ddrmr = (struct ddrmr_regs *)DDR_BASE_ADDR;
+ imx_iomux_v3_setup_multiple_pads(pads, pads_count);
+}
- writel(DDRMC_PHY_DQ_TIMING, ddrmr-phy[0]);
- writel(DDRMC_PHY_DQ_TIMING, ddrmr-phy[16]);
- writel(DDRMC_PHY_DQ_TIMING, ddrmr-phy[32]);
+static struct ddrmc_reg_setting default_phy_settings[] = {
+ { DDRMC_PHY_DQ_TIMING, 0 },
+ { DDRMC_PHY_DQ_TIMING, 16 },
+ { DDRMC_PHY_DQ_TIMING, 32 },
- writel(DDRMC_PHY_DQS_TIMING, ddrmr-phy[1]);
- writel(DDRMC_PHY_DQS_TIMING, ddrmr-phy[17]);
+ { DDRMC_PHY_DQS_TIMING, 1 },
+ { DDRMC_PHY_DQS_TIMING, 17 },
- writel(DDRMC_PHY_CTRL, ddrmr-phy[2]);
- writel(DDRMC_PHY_CTRL, ddrmr-phy[18]);
- writel(DDRMC_PHY_CTRL, ddrmr-phy[34]);
+ { DDRMC_PHY_CTRL, 2 },
+ { DDRMC_PHY_CTRL, 18 },
+ { DDRMC_PHY_CTRL, 34 },
- writel(DDRMC_PHY_MASTER_CTRL, ddrmr-phy[3]);
- writel(DDRMC_PHY_MASTER_CTRL, ddrmr-phy[19]);
- writel(DDRMC_PHY_MASTER_CTRL, ddrmr-phy[35]);
+ { DDRMC_PHY_MASTER_CTRL, 3 },
+ { DDRMC_PHY_MASTER_CTRL, 19 },
+ { DDRMC_PHY_MASTER_CTRL, 35 },
- writel(DDRMC_PHY_SLAVE_CTRL, ddrmr-phy[4]);
- writel(DDRMC_PHY_SLAVE_CTRL, ddrmr-phy[20]);
- writel(DDRMC_PHY_SLAVE_CTRL, ddrmr-phy[36]);
+ { DDRMC_PHY_SLAVE_CTRL, 4 },
+ { DDRMC_PHY_SLAVE_CTRL, 20 },
+ { DDRMC_PHY_SLAVE_CTRL, 36 },
/* LPDDR2 only parameter */
- writel(DDRMC_PHY_OFF, ddrmr-phy[49]);
+ { DDRMC_PHY_OFF, 49 },
- writel(DDRMC_PHY50_DDR3_MODE |
-DDRMC_PHY50_EN_SW_HALF_CYCLE, ddrmr-phy[50]);
+ { DDRMC_PHY50_DDR3_MODE | DDRMC_PHY50_EN_SW_HALF_CYCLE, 50 },
/* Processor Pad ODT settings */
- writel(DDRMC_PHY_PROC_PAD_ODT, ddrmr-phy[52]);
-}
+ { DDRMC_PHY_PROC_PAD_ODT, 52 },
-static void ddrmc_ctrl_lvl_init(struct ddrmc_lvl_info *lvl)
-{
- struct ddrmr_regs *ddrmr = (struct ddrmr_regs *)DDR_BASE_ADDR;
- u32 cr102 = 0, cr105 = 0, cr106 = 0, cr110 = 0;
+ /* end marker */
+ { 0, -1 }
+};
- if (lvl-wrlvl_reg_en) {
- writel(DDRMC_CR97_WRLVL_EN, ddrmr-cr[97]);
- writel(DDRMC_CR98_WRLVL_DL_0(lvl-wrlvl_dl_0), ddrmr-cr[98]);
- writel(DDRMC_CR99_WRLVL_DL_1(lvl-wrlvl_dl_1), ddrmr-cr[99]);
- }
-
- if (lvl-rdlvl_reg_en) {
- cr102 |= DDRMC_CR102_RDLVL_REG_EN;
- cr105 |= DDRMC_CR105_RDLVL_DL_0(lvl-rdlvl_dl_0);
- cr110 |= DDRMC_CR110_RDLVL_DL_1(lvl-rdlvl_dl_1);
- }
-
- if (lvl-rdlvl_gt_reg_en) {
- cr102 |= DDRMC_CR102_RDLVL_GT_REGEN;
- cr106 |= DDRMC_CR106_RDLVL_GTDL_0(lvl-rdlvl_gt_dl_0);
- cr110 |= DDRMC_CR110_RDLVL_GTDL_1(lvl-rdlvl_gt_dl_1);
- }
-
- writel(cr102, ddrmr-cr[102]);
- writel(cr105, ddrmr-cr[105]);
- writel(cr106, ddrmr-cr[106]);
- writel(cr110,
Re: [U-Boot] [PATCH] ARM: cache-cp15: Make sure EAE is not enabled
On 18 June 2015 at 17:13, Simon Glass s...@chromium.org wrote: Hi, On 18 June 2015 at 01:19, Tomeu Vizoso tomeu.viz...@collabora.com wrote: Hello, any news on this one? Thanks, Tomeu On 30 April 2015 at 09:23, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: +Albert, +Marek, On Tue, 2015-04-28 at 14:21 +0200, Tomeu Vizoso wrote: This could happen if we are being chainloaded by Coreboot with LPAE enabled, as is the case on the Tegra-based Chromebooks. Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com From the documentation of recent ARM cores it looks like 0 is the reset value for that register, so explicitly ensuring it has that value seems sane. I'm wary of giving a reviewed-by though as i don't know that part of u-boot well enough to say it's the right spot. However, as we're now using successfully using a Nyan big board with this u-boot patch in kernelci[0] i can happily say: Tested-By: Sjoerd Simons sjoerd.sim...@collabora.co.uk 0: http://kernelci.org/boot/tegra124-nyan-big/ --- arch/arm/lib/cache-cp15.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c index 0291afa..78fb429 100644 --- a/arch/arm/lib/cache-cp15.c +++ b/arch/arm/lib/cache-cp15.c @@ -96,6 +96,10 @@ static inline void mmu_setup(void) dram_bank_mmu_setup(i); } + /* Make sure EAE is not enabled */ + asm volatile(mcr p15, 0, %0, c2, c0, 2 + : : r (0) : memory); + /* Copy the page table address to cp15 */ asm volatile(mcr p15, 0, %0, c2, c0, 0 : : r (gd-arch.tlb_addr) : memory); Does this apply to all ARM cores? Should it have #ifdef CONFIG_ARMV7 or similar? Don't know, TBH. Resetting that register will select the TTBR0 and a page table boundary size of 16KB, which AFAICS is expected in U-Boot anyways. On ARMv6, there isn't a EAE bit, so only the above will happen. I cannot say if it's a good idea or not to reset the TTBCR just in case. Thanks, Tomeu Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MinnowBoard Max uboot
Hi Bin, I have tried both suggestions and the kernel boot still hangs in the same place. I have enclosed a snipit from boot that shows the command line. Thanks, Tom -Original Message- From: Bin Meng [mailto:bmeng...@gmail.com] Sent: Thursday, June 18, 2015 9:16 PM To: Beaman, Thomas Cc: Simon Glass; u-boot@lists.denx.de Subject: Re: [U-Boot] MinnowBoard Max uboot Can you try typing 'run ramboot' on the U-Boot shell to load linux kernel? Or below ... Or append acpi=off to the kernel command line manually, to see how it goes. = run ramboot Using RTL8169#0 device TFTP from server 10.40.101.102; our IP address is 10.40.101.244 Filename 'atom_64/kernel'. Load address: 0x1000 Loading: ## 5.6 MiB 3.6 MiB/s done Bytes transferred = 5861312 (596fc0 hex) Using RTL8169#0 device TFTP from server 10.40.101.102; our IP address is 10.40.101.244 Filename 'atom_64/ramdisk'. Load address: 0x2000 Loading: ## 29.1 MiB 3.5 MiB/s done Bytes transferred = 30497951 (1d15c9f hex) Valid Boot Flag Setup Size = 0x3e00 Magic signature found Using boot protocol version 2.0c Linux kernel version 3.10.62-ltsi-WR6.0.0.20_standard (tbeaman@wocket) #1 SMP PREEMPT Wed Jun 17 15:19:47 EDT 2015 Building boot_params at 0x0009 Loading bzImage at address 10 (5845440 bytes) Magic signature found Initial RAM disk at linear address 0x2000, size 30497951 bytes Kernel command line: root=/dev/ram rw ip=10.40.101.244:10.40.101.102::255.255.255.0:x86:eth0:off console=ttyS0,115200 acpi=off ramdisk_size=30 Starting kernel ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] ARM: DRA72x: fix io delay calibration for ethernet
On 16:45-20150619, Mugunthan V N wrote:
Ethernet on DRA72x EVM is not working as the io delay calibration
value is not correct. Fixing this with the correct values and
verified this on DRA72x EVM with tftp file transfer
This description is not entirely accurate. I propose the following:
we currently use in-development IODelay values for J6eco which are
proposed in the data sheet, however, DRA72x EVM uses DP83865 ethernet
Phy over RGMII. The PHY characteristics and routing choices made on
the EVM, make the current iodelay values fail ethernet communication.
Instead, we need to choose custom values for DRA72x-evm specifically
designed for the PHY and routing on the platform for ethernet to
function.
Cc: Nishanth Menon n...@ti.com
Cc: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
board/ti/dra7xx/mux_data.h | 48
+++---
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index c9301a5..0ca3c51 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -156,30 +156,30 @@ const struct pad_conf_entry early_padconf[] = {
#ifdef CONFIG_IODELAY_RECALIBRATION
const struct iodelay_cfg_entry iodelay_cfg_array[] = {
- {0x6F0, 480, 0}, /* RGMMI0_RXC_IN */
- {0x6FC, 111, 1641}, /* RGMMI0_RXCTL_IN */
- {0x708, 272, 1116}, /* RGMMI0_RXD0_IN */
- {0x714, 243, 1260}, /* RGMMI0_RXD1_IN */
- {0x720, 0, 1614}, /* RGMMI0_RXD2_IN */
- {0x72C, 105, 1673}, /* RGMMI0_RXD3_IN */
- {0x740, 531, 120}, /* RGMMI0_TXC_OUT */
- {0x74C, 11, 60}, /* RGMMI0_TXCTL_OUT */
- {0x758, 7, 120}, /* RGMMI0_TXD0_OUT */
- {0x764, 0, 0}, /* RGMMI0_TXD1_OUT */
- {0x770, 276, 120}, /* RGMMI0_TXD2_OUT */
- {0x77C, 440, 120}, /* RGMMI0_TXD3_OUT */
- {0xAB0, 702, 0}, /* CFG_VIN2A_D18_IN */
- {0xABC, 136, 976}, /* CFG_VIN2A_D19_IN */
- {0xAD4, 210, 1357}, /* CFG_VIN2A_D20_IN */
- {0xAE0, 189, 1462}, /* CFG_VIN2A_D21_IN */
- {0xAEC, 232, 1278}, /* CFG_VIN2A_D22_IN */
- {0xAF8, 0, 1397}, /* CFG_VIN2A_D23_IN */
- {0xA70, 1551, 115}, /* CFG_VIN2A_D12_OUT */
- {0xA7C, 816, 0}, /* CFG_VIN2A_D13_OUT */
- {0xA88, 876, 0}, /* CFG_VIN2A_D14_OUT */
- {0xA94, 312, 0}, /* CFG_VIN2A_D15_OUT */
- {0xAA0, 58, 0}, /* CFG_VIN2A_D16_OUT */
- {0xAAC, 0, 0}, /* CFG_VIN2A_D17_OUT */
Add a comment for custom values for J6-evm
+ {0x6F0, 359, 0}, /* RGMMI0_RXC_IN */
+ {0x6FC, 129, 1896}, /* RGMMI0_RXCTL_IN */
+ {0x708, 80, 1391}, /* RGMMI0_RXD0_IN */
+ {0x714, 196, 1522}, /* RGMMI0_RXD1_IN */
+ {0x720, 40, 1860}, /* RGMMI0_RXD2_IN */
+ {0x72C, 0, 1956}, /* RGMMI0_RXD3_IN */
+ {0x740, 0, 220}, /* RGMMI0_TXC_OUT */
+ {0x74C, 1820, 180}, /* RGMMI0_TXCTL_OUT */
+ {0x758, 1740, 440}, /* RGMMI0_TXD0_OUT */
+ {0x764, 1740, 240}, /* RGMMI0_TXD1_OUT */
+ {0x770, 1680, 380}, /* RGMMI0_TXD2_OUT */
+ {0x77C, 1740, 440}, /* RGMMI0_TXD3_OUT */
Comment here providing that these values are for u-boot using RGMII1
configuration on VIN2a_x pins.
+ {0xAB0, 596, 0}, /* CFG_VIN2A_D18_IN */
+ {0xABC, 314, 980}, /* CFG_VIN2A_D19_IN */
+ {0xAD4, 241, 1536}, /* CFG_VIN2A_D20_IN */
+ {0xAE0, 103, 1689}, /* CFG_VIN2A_D21_IN */
+ {0xAEC, 161, 1563}, /* CFG_VIN2A_D22_IN */
+ {0xAF8, 0, 1613}, /* CFG_VIN2A_D23_IN */
+ {0xA70, 0, 200}, /* CFG_VIN2A_D12_OUT */
+ {0xA7C, 1560, 140}, /* CFG_VIN2A_D13_OUT */
+ {0xA88, 1700, 0}, /* CFG_VIN2A_D14_OUT */
+ {0xA94, 1260, 0}, /* CFG_VIN2A_D15_OUT */
+ {0xAA0, 1400, 0}, /* CFG_VIN2A_D16_OUT */
+ {0xAAC, 1290, 0}, /* CFG_VIN2A_D17_OUT */
};
#endif
Otherwise, the values look good. Along with the mentioned changes,
please feel free to Add:
Reviewed-by: Nishanth Menon n...@ti.com
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] vf610: refactor DDRMC code
Bonjour Stefan, Le Fri, 19 Jun 2015 17:13:12 +0200, Stefan Agner stefan.ag...@toradex.com a écrit : Hi Albert, On 19.06.2015 14:18, Albert ARIBAUD (3ADEV) wrote: The VF610 DDRMC driver code contains settings which are board-specific. Move these out to boards so that new boards can define their own without having to modify the driver. Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr --- arch/arm/imx-common/ddrmc-vf610.c | 239 ++ arch/arm/include/asm/arch-vf610/ddrmc-vf610.h | 60 +-- board/freescale/vf610twr/vf610twr.c | 181 +-- board/toradex/colibri_vf/colibri_vf.c | 169 +- 4 files changed, 312 insertions(+), 337 deletions(-) So this goes basically back to setting all DDR registers directly from boards? What we tried to do here is to factor out the memory chip specific data (JEDEC). The idea behind this is it would make it simpler to add new RAM timings if a new RAM vendor is used on a different board revision... With your changes it will be unnecessarily hard to add just a new RAM timing for a new board revision... I could probably factor back out the JEDEC settings, but there are still differences in the lists of registers to write between the existing vf610twr/colibri_vf and the new pcm052, especially the PHY regs but elsewhere too, and there are some writes in the driver that the PCM052 does not have. As I wanted to leave the existing boards strictly unaffected, and as I did not want to start sprinkling '#if defined(some-board)' over the driver code, I went for a fully board-controlled design so that no board could possibly be affected by any future change to the driver. How about a mix? I could keep the JEDEC and lvl pointers in the DDR controller init call arguments and append per-boards CR and PHY arrays. The driver would do the JEDEC writes (thus keeping JEDEC DDR3 additions simple), the LVL writes if not NULL, then the per-board CR writes if not NULL, then the current common PHY writes, then the per-board PHY writes if not null. This would keep common parts (JEDEC and minimal settings) in the driver while allowing board their own specific settings -- even overriding the driver settings, since the per-board writes would come last before CR000 is rewritten. Would that be ok ? -- Stefan Cordialement, Albert ARIBAUD 3ADEV ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: Configure expansion ROM during auto config process
On Fri, Jun 19, 2015 at 04:15:04PM +0800, Bin Meng wrote:
Currently PCI expansion ROM address is assigned by a call to
pciauto_setup_rom() outside of the pci auto config process.
This does not work when expansion ROM is on a device behind
PCI bridge where bridge's memory limit register was already
programmed to a value that does not cover the newly assigned
expansion ROM address. To fix this, we should configure the
ROM address during the auto config process.
Definitely the correct approach for the reason mentioned. There's
an issue though with the behavior of the existing expansion ROM
probe code that should be mentioned, see below.
Otherwise, looks good.
Reviewed-by: Matt Porter mpor...@konsulko.com
Signed-off-by: Bin Meng bmeng...@gmail.com
---
drivers/pci/pci_auto.c | 40 ++--
drivers/pci/pci_rom.c | 5 -
include/pci.h | 9 -
3 files changed, 14 insertions(+), 40 deletions(-)
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index 7c10983..92b4933 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -182,36 +182,24 @@ void pciauto_setup_device(struct pci_controller *hose,
bar_nr++;
}
- pci_hose_write_config_word(hose, dev, PCI_COMMAND, cmdstat);
- pci_hose_write_config_byte(hose, dev, PCI_CACHE_LINE_SIZE,
- CONFIG_SYS_PCI_CACHE_LINE_SIZE);
- pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
-}
-
-int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev)
-{
- pci_addr_t bar_value;
- pci_size_t bar_size;
- u32 bar_response;
- u16 cmdstat = 0;
-
+ /* Configure the expansion ROM address */
pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS, 0xfffe);
pci_hose_read_config_dword(hose, dev, PCI_ROM_ADDRESS, bar_response);
- if (!bar_response)
- return -ENOENT;
-
- bar_size = -(bar_response ~1);
- DEBUGF(PCI Autoconfig: ROM, size=%#x, , bar_size);
- if (pciauto_region_allocate(hose-pci_mem, bar_size, bar_value) == 0) {
- pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS,
- bar_value);
+ if (bar_response) {
+ bar_size = -(bar_response ~1);
+ DEBUGF(PCI Autoconfig: ROM, size=%#x, , bar_size);
+ if (pciauto_region_allocate(mem, bar_size, bar_value) == 0) {
+ pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS,
+ bar_value);
+ }
+ cmdstat |= PCI_COMMAND_MEMORY;
+ DEBUGF(\n);
}
- DEBUGF(\n);
- pci_hose_read_config_word(hose, dev, PCI_COMMAND, cmdstat);
- cmdstat |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
- pci_hose_write_config_word(hose, dev, PCI_COMMAND, cmdstat);
- return 0;
+ pci_hose_write_config_word(hose, dev, PCI_COMMAND, cmdstat);
+ pci_hose_write_config_byte(hose, dev, PCI_CACHE_LINE_SIZE,
+CONFIG_SYS_PCI_CACHE_LINE_SIZE);
+ pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
This is a good place to mention that there's a (IMHO) latent bug in the
existing expansion ROM support. The spec mentions that simply having
a BAR decoder active does not mean there's an expansion ROM present as
it could be depoped whether socketed (old school) or not. The
pci_rom_probe() code does properly check for the ROM header signature
after ROM address decoding is enabled but does not exhibit proper error
handling on exit. Rather than leaving the ROM expansion address active
it should disable decoding on an invalid header signature. e.g.:
if (le16_to_cpu(rom_header-signature) != PCI_ROM_HDR) {
printf(Incorrect expansion ROM header signature %04x,
disabling\n,
le16_to_cpu(rom_header-signature));
+ /* Disable expansion ROM address decoding */
+ pci_write_config_dword(dev, PCI_ROM_ADDRESS, rom_address);
return -EINVAL;
}
I don't have a way to test this effectively other than by inspection but
I could send a proper patch.
-Matt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] vf610: refactor DDRMC code
Bonjour Stefan, Le Fri, 19 Jun 2015 17:13:12 +0200, Stefan Agner stefan.ag...@toradex.com a écrit : Hi Albert, On 19.06.2015 14:18, Albert ARIBAUD (3ADEV) wrote: The VF610 DDRMC driver code contains settings which are board-specific. Move these out to boards so that new boards can define their own without having to modify the driver. Signed-off-by: Albert ARIBAUD (3ADEV) albert.arib...@3adev.fr --- arch/arm/imx-common/ddrmc-vf610.c | 239 ++ arch/arm/include/asm/arch-vf610/ddrmc-vf610.h | 60 +-- board/freescale/vf610twr/vf610twr.c | 181 +-- board/toradex/colibri_vf/colibri_vf.c | 169 +- 4 files changed, 312 insertions(+), 337 deletions(-) So this goes basically back to setting all DDR registers directly from boards? What we tried to do here is to factor out the memory chip specific data (JEDEC). The idea behind this is it would make it simpler to add new RAM timings if a new RAM vendor is used on a different board revision... With your changes it will be unnecessarily hard to add just a new RAM timing for a new board revision... I could probably factor back out the JEDEC settings, but there are still differences in the lists of registers to write between the existing vf610twr/colibri_vf and the new pcm052, especially the PHY regs but elsewhere too, and there are some writes in the driver that the PCM052 does not have. As I wanted to leave the existing boards strictly unaffected, and as I did not want to start sprinkling '#if defined(some-board)' over the driver code, I went for a fully board-controlled design so that no board could possibly be affected by any future change to the driver. How about a mix? I could keep the JEDEC and lvl pointers in the DDR controller init call arguments and append per-boards CR and PHY arrays. The driver would do the JEDEC writes (thus keeping JEDEC DDR3 additions simple), the LVL writes if not NULL, then the per-board CR writes if not NULL, then the current common PHY writes, then the per-board PHY writes if not null. This would keep common parts (JEDEC and minimal settings) in the driver while allowing board their own specific settings -- even overriding the driver settings, since the per-board writes would come last before CR000 is rewritten. Would that be ok ? -- Stefan Cordialement, Albert ARIBAUD 3ADEV ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
The following changes since commit c6265f7f3410b5e5763181cdd123a3f6fcd9fd58: CPCI4052: Remove CONFIG_SYS_LONGHELP (2015-06-18 16:19:00 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git HEAD for you to fetch changes up to de451493f1b6dfcc572763be421500754bfc6b2f: usb: kbd: Disable idle input reports when we do not need them (2015-06-19 14:33:29 +0200) Hans de Goede (3): usb.h: Always declare usb function prototypes usb: ehci: Properly deal with data toggle for interrupt endpoints usb: kbd: Disable idle input reports when we do not need them common/usb_kbd.c| 4 +++- drivers/usb/host/ehci-hcd.c | 26 +++--- include/usb.h | 15 --- 3 files changed, 22 insertions(+), 23 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
