Re: [U-Boot] Ethernet not found on Arria 5.
Hi Marek, Dinh, > Are you booting using mainline U-Boot SPL ? :-) No, we use SPL from U-Boot 2013. I can quess what you will say now, but it somehow worked before (combination SPL + U-Boot from 2013). Is there a way to capture fpga dumps? I can then compare them to working case. I can assume that there will be lots of differences and I would have to check them manually, but it's better than nothing I think. Best regards, Denis Bakhvalov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] fsl: esdhc: consolidate fsl_esdhc_cfg structure
We can use phys_addr_to for esdhc_base to discard
the #ifdef.
Signed-off-by: Peng Fan
Cc: York Sun
Cc: Yangbo Lu
Cc: Hector Palacios
Cc: Eric Nelson
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Pantelis Antoniou
Cc: Simon Glass
---
include/fsl_esdhc.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index 073048f..fa760a5 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -168,11 +168,7 @@
#define ESDHC_VENDORSPEC_VSELECT 0x0002 /* Use 1.8V */
struct fsl_esdhc_cfg {
-#ifdef CONFIG_FSL_LAYERSCAPE
- u64 esdhc_base;
-#else
- u32 esdhc_base;
-#endif
+ phys_addr_t esdhc_base;
u32 sdhc_clk;
u8 max_bus_width;
struct mmc_config cfg;
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] fsl: esdhc: support driver model
Support Driver Model for fsl esdhc driver.
In order to minimize the change, reuse the fsl_esdhc_initialize function.
This new way is to fill an fsl_esdhc_cfg struture and pass it
to fsl_esdhc_initialize, just like the code in different board codes.
Introduce a 'struct mmc *mmc' entry in fsl_esdhc_cfg structure,
otherwise fsl_esdhc_initialize may need to be restructured which will
cause lots changes for board code.
Since clk driver is not implemented, use mxc_get_clock here to
fill cfg->sdhc_clk. Anyway we can utilize the pinctrl imx driver
now, except the SPL part, we can drop the pinmux settings from
board file for mmc.
There are so many "ifdef" in the file, maybe we can use driver data
or quirks to cover these. But to minimize changes for this patch,
these are not included. Later we can try to discard the nasty
ifdef.
Has been tested on i.MX6UL 9x9 EVK board:
"
=>dm tree
simple_bus [ + ]| `-- aips-bus@0210
mmc[ + ]| |-- usdhc@0219
mmc[ + ]| |-- usdhc@02194000
=> mmc list
FSL_SDHC: 0 (SD)
FSL_SDHC: 1 (SD)
"
Signed-off-by: Peng Fan
Cc: York Sun
Cc: Yangbo Lu
Cc: Hector Palacios
Cc: Eric Nelson
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Pantelis Antoniou
Cc: Simon Glass
---
drivers/mmc/fsl_esdhc.c | 81 +
include/fsl_esdhc.h | 1 +
2 files changed, 82 insertions(+)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index ea5f4bf..1bd2174 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -20,6 +20,8 @@
#include
#include
#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -739,6 +741,8 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg
*cfg)
if (mmc == NULL)
return -1;
+ cfg->mmc = mmc;
+
return 0;
}
@@ -819,3 +823,80 @@ void fdt_fixup_esdhc(void *blob, bd_t *bd)
4 + 1, 1);
}
#endif
+
+#ifdef CONFIG_DM_MMC
+static int fsl_esdhc_probe(struct udevice *dev)
+{
+ struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+ struct fsl_esdhc_cfg *cfg = dev_get_priv(dev);
+ const void *fdt = gd->fdt_blob;
+ fdt_addr_t addr;
+ unsigned int val;
+ int node = dev->of_offset;
+ int ret;
+
+ addr = dev_get_addr(dev);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ cfg->esdhc_base = (phys_addr_t)addr;
+
+ val = fdtdec_get_int(fdt, node, "bus-width", -1);
+ if (val == 8)
+ cfg->max_bus_width = 8;
+ else if (val == 4)
+ cfg->max_bus_width = 4;
+ else
+ cfg->max_bus_width = 1;
+
+ /*
+* TODO:
+* Because lack of clk driver, if SDHC clk is not enabled,
+* need to enable it first before this driver is invoked.
+*
+* we use MXC_ESDHC_CLK to get clk freq.
+* If one would like to make this function work,
+* the aliases should be provided in dts as this:
+*
+* aliases {
+* mmc0 = &usdhc1;
+* mmc1 = &usdhc2;
+* mmc2 = &usdhc3;
+* mmc3 = &usdhc4;
+* };
+* Then if your board only supports mmc2 and mmc3, but we can
+* correctly get the seq as 2 and 3, then let mxc_get_clock
+* work as expected.
+*/
+ cfg->sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK + dev->seq);
+ if (cfg->sdhc_clk <= 0) {
+ dev_err(dev, "Unable to get clk for %s\n", dev->name);
+ return -EINVAL;
+ }
+
+ ret = fsl_esdhc_initialize(NULL, cfg);
+ if (ret)
+ return ret;
+
+ upriv->mmc = cfg->mmc;
+
+ return 0;
+}
+
+static const struct udevice_id fsl_esdhc_ids[] = {
+ { .compatible = "fsl,imx6ul-usdhc", },
+ { .compatible = "fsl,imx6sx-usdhc", },
+ { .compatible = "fsl,imx6sl-usdhc", },
+ { .compatible = "fsl,imx6q-usdhc", },
+ { .compatible = "fsl,imx7d-usdhc", },
+ { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(fsl_esdhc) = {
+ .name = "fsl_esdhc_mmc",
+ .id = UCLASS_MMC,
+ .of_match = fsl_esdhc_ids,
+ .probe = fsl_esdhc_probe,
+ .priv_auto_alloc_size = sizeof(struct fsl_esdhc_cfg),
+};
+#endif
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index fa760a5..e0d3265 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -172,6 +172,7 @@ struct fsl_esdhc_cfg {
u32 sdhc_clk;
u8 max_bus_width;
struct mmc_config cfg;
+ struct mmc *mmc;
};
/* Select the correct accessors depending on endianess */
--
2.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] drivers: musb-new: fix compilation error for MIPS.
On 03/07/2016 09:18 PM, Daniel Schwierzeck wrote:
> 2016-03-07 14:19 GMT+01:00 Purna Chandra Mandal :
>> MIPS arch implements writes{b,w,l,q}, reads{b,w,l,q}
>> whereas other archs implement __raw version of them.
>> So defining macro writes{bwlq}() to __raw_writes{bwlq}()
>> (and similarly for reads{bwlq}) is not necessary for MIPS.
>>
>> Signed-off-by: Purna Chandra Mandal
>> ---
>>
>> Changes in v2: None
>>
>> drivers/usb/musb-new/linux-compat.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/usb/musb-new/linux-compat.h
>> b/drivers/usb/musb-new/linux-compat.h
>> index 46f83d9..9ac48c1 100644
>> --- a/drivers/usb/musb-new/linux-compat.h
>> +++ b/drivers/usb/musb-new/linux-compat.h
>> @@ -13,12 +13,14 @@
>> printf(fmt, ##args);\
>> ret_warn; })
>>
>> +#if !defined(CONFIG_MIPS)
>> #define writesl(a, d, s) __raw_writesl((unsigned long)a, d, s)
>> #define readsl(a, d, s) __raw_readsl((unsigned long)a, d, s)
>> #define writesw(a, d, s) __raw_writesw((unsigned long)a, d, s)
>> #define readsw(a, d, s) __raw_readsw((unsigned long)a, d, s)
>> #define writesb(a, d, s) __raw_writesb((unsigned long)a, d, s)
>> #define readsb(a, d, s) __raw_readsb((unsigned long)a, d, s)
>> +#endif
> I guess the current musb-new users are ARM boards only. Thus this
> should be moved to arch/arm/asm/io.h. Adding I/O primitives to a
> architecture-independent linux-compat.h was wrong from the beginning.
Makes sense! ARM Linux also defines readsl(or similar) to their __raw
version in arch/arm/include/asm/io.h file.
>> #define device_init_wakeup(dev, a) do {} while (0)
>>
>> --
>> 1.8.3.1
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: DRA7: DDR: Enable SR in Power Management Control
On Wed, Mar 09, 2016 at 05:39:56PM +0530, Lokesh Vutla wrote: > From: Nishanth Menon > > If EMIF is idle for certain amount of DDR cycles, EMIF will put the > DDR in self refresh mode to save power if EMIF_PWR_MGMT_CTRL register > is programmed. And also before entering suspend-resume ddr needs to > be put in self-refresh. Linux kernel does not program this register > before entering suspend and relies on u-boot setting. > So configuring it in u-boot. > > Signed-off-by: Nishanth Menon > Signed-off-by: Lokesh Vutla Tested-by: Tom Rini Reviewed-by: Tom Rini -- 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] Ethernet not found on Arria 5.
On 03/10/2016 09:58 AM, Bakhvalov, Denis (Nokia - PL/Wroclaw) wrote: > Hi Marek, Dinh, Hi, >> Are you booting using mainline U-Boot SPL ? :-) > > No, we use SPL from U-Boot 2013. > I can quess what you will say now, but it somehow worked before (combination > SPL + U-Boot from 2013). I will say exactly that, you are asking for support in mainline mailing list, while you don't even use mainline. What sort of reaction do you even expect ? > Is there a way to capture fpga dumps? > I can then compare them to working case. > I can assume that there will be lots of differences and I would have to check > them manually, but it's better than nothing I think. Why are you constantly hung on this FPGA part ? The ethernet is not routed through the FPGA, it is connected directly to the HPS. Thus, you don't have to care about the FPGA at all, you only care about the configuration of the HPS. > Best regards, > Denis Bakhvalov > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] drivers: mtd: add Microchip PIC32 internal non-CFI flash driver.
PIC32 embedded flash banks are memory mapped, directly read by CPU,
and programming (erase followed by write) operation on them are
handled by on-chip NVM controller.
Signed-off-by: Purna Chandra Mandal
---
drivers/mtd/Kconfig | 6 +
drivers/mtd/Makefile | 1 +
drivers/mtd/pic32_flash.c | 377 ++
include/flash.h | 5 +-
4 files changed, 388 insertions(+), 1 deletion(-)
create mode 100644 drivers/mtd/pic32_flash.c
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index c58841e..e3c6b9f 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -30,6 +30,12 @@ config ALTERA_QSPI
endmenu
+config FLASH_PIC32
+ bool "Microchip PIC32 Flash driver"
+ help
+ This enables access to Microchip PIC32 internal non-CFI flash
+ chips through PIC32 Non-Volatile-Memory Controller.
+
source "drivers/mtd/nand/Kconfig"
source "drivers/mtd/spi/Kconfig"
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 7f018a4..9380085 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -19,4 +19,5 @@ obj-$(CONFIG_HAS_DATAFLASH) += dataflash.o
obj-$(CONFIG_FTSMC020) += ftsmc020.o
obj-$(CONFIG_FLASH_CFI_LEGACY) += jedec_flash.o
obj-$(CONFIG_MW_EEPROM) += mw_eeprom.o
+obj-$(CONFIG_FLASH_PIC32) += pic32_flash.o
obj-$(CONFIG_ST_SMI) += st_smi.o
diff --git a/drivers/mtd/pic32_flash.c b/drivers/mtd/pic32_flash.c
new file mode 100644
index 000..9a226b1
--- /dev/null
+++ b/drivers/mtd/pic32_flash.c
@@ -0,0 +1,377 @@
+/*
+ * Copyright (C) 2015
+ * Cristian Birsan
+ * Purna Chandra Mandal
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+
+/* NVM Controller registers */
+struct pic32_reg_nvm {
+ struct pic32_reg_atomic ctrl;
+ struct pic32_reg_atomic key;
+ struct pic32_reg_atomic addr;
+ struct pic32_reg_atomic data;
+};
+
+/* NVM operations */
+#define NVMOP_NOP 0
+#define NVMOP_WORD_WRITE 1
+#define NVMOP_PAGE_ERASE 4
+
+/* NVM control bits */
+#define NVM_WR BIT(15)
+#define NVM_WREN BIT(14)
+#define NVM_WRERR BIT(13)
+#define NVM_LVDERR BIT(12)
+
+/* NVM programming unlock register */
+#define LOCK_KEY 0x0
+#define UNLOCK_KEY10xaa996655
+#define UNLOCK_KEY20x556699aa
+
+/* PIC32 flash banks consist of number of pages, each page
+ * into number of row and rows are into number of words.
+ * Here we will maintain page information instead of sector.
+ */
+flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS];
+static struct pic32_reg_nvm *nvm_regs_p;
+
+static inline void flash_initiate_operation(u32 nvmop)
+{
+ /* set operation */
+ writel(nvmop, &nvm_regs_p->ctrl.raw);
+
+ /* enable flash write */
+ writel(NVM_WREN, &nvm_regs_p->ctrl.set);
+
+ /* unlock sequence */
+ writel(LOCK_KEY, &nvm_regs_p->key.raw);
+ writel(UNLOCK_KEY1, &nvm_regs_p->key.raw);
+ writel(UNLOCK_KEY2, &nvm_regs_p->key.raw);
+
+ /* initiate operation */
+ writel(NVM_WR, &nvm_regs_p->ctrl.set);
+}
+
+static int flash_wait_till_busy(const char *func, ulong timeout)
+{
+ int ret = wait_for_bit(__func__, &nvm_regs_p->ctrl.raw,
+ NVM_WR, false, timeout, false);
+
+ return ret ? ERR_TIMOUT : ERR_OK;
+}
+
+static inline int flash_complete_operation(void)
+{
+ u32 v;
+
+ v = readl(&nvm_regs_p->ctrl.raw);
+ if (v & NVM_WRERR) {
+ printf("Error in Block Erase - Lock Bit may be set!\n");
+ flash_initiate_operation(NVMOP_NOP);
+ return ERR_PROTECTED;
+ }
+
+ if (v & NVM_LVDERR) {
+ printf("Error in Block Erase - low-vol detected!\n");
+ flash_initiate_operation(NVMOP_NOP);
+ return ERR_NOT_ERASED;
+ }
+
+ /* disable flash write or erase operation */
+ writel(NVM_WREN, &nvm_regs_p->ctrl.clr);
+
+ return ERR_OK;
+}
+
+int flash_erase(flash_info_t *info, int s_first, int s_last)
+{
+ ulong sect_start, sect_end, flags;
+ int prot, sect;
+ int rc;
+
+ if ((info->flash_id & FLASH_VENDMASK) != FLASH_MAN_MCHP) {
+ printf("Can't erase unknown flash type %08lx - aborted\n",
+ info->flash_id);
+ return ERR_UNKNOWN_FLASH_VENDOR;
+ }
+
+ if ((s_first < 0) || (s_first > s_last)) {
+ printf("- no sectors to erase\n");
+ return ERR_INVAL;
+ }
+
+ prot = 0;
+ for (sect = s_first; sect <= s_last; ++sect) {
+ if (info->protect[sect])
+ prot++;
+ }
+
+ if (prot)
+ printf("- Warning: %d protected sectors will not be erased!\n",
+ prot);
+ else
+ printf("\n");
+
+ /* erase on unprotected sectors */
+
[U-Boot] [PATCH v2] exynos: Set CNTFRQ
Commit 73a1cb27 moved the check whether we should set the architected timer frequency from CONFIG_SYS_CLK_FREQ to CONFIG_TIMER_CLK_FREQ, but did not update all users of it. The one where I (finally) realized why KVM didn't work is the Arndale board, so this patch adds the respective define to it. Signed-off-by: Alexander Graf Fixes: 73a1cb27 --- v1 -> v2: - Map to CONFIG_SYS_CLK_FREQ instead of redefining to the same number --- include/configs/exynos-common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/exynos-common.h b/include/configs/exynos-common.h index 852829c..b61f889 100644 --- a/include/configs/exynos-common.h +++ b/include/configs/exynos-common.h @@ -31,6 +31,7 @@ /* input clock of PLL: 24MHz input clock */ #define CONFIG_SYS_CLK_FREQ2400 +#define CONFIG_TIMER_CLK_FREQ CONFIG_SYS_CLK_FREQ #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_CMDLINE_TAG -- 1.8.5.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: mtd: add Microchip PIC32 internal non-CFI flash driver.
On Thursday 10 March 2016 06:42 PM, Purna Chandra Mandal wrote: PIC32 embedded flash banks are memory mapped, directly read by CPU, and programming (erase followed by write) operation on them are handled by on-chip NVM controller. Can you please add some more description to understand bit more, which kind of flash it is, parallel NOR? thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Ethernet not found on Arria 5.
On 03/09/2016 06:25 PM, Marek Vasut wrote: > > Thanks for the test! > > The speed looks weird, it should be in the 2-3MiB range. > > Are you booting using mainline U-Boot SPL ? :-) > Yes, I'm using mainline SPL. This Arria5 board is really old so I can't really say that I have good working HW. But ethernet does seem to be working for me. I look through all of the obvious areas(IOCSR, skew phy settings, system manager for setting the PHY modes) and I can't see anything wrong with the A5 ethernet support. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] rockchip: rk3288: correct sdram setting
On 6 March 2016 at 23:51, Chris Zhong wrote: > The DMC driver in v3.14 kernel[0] get the ddr setting from PMU_SYS_REG2, > and it expects uboot to store the value using a same protocol. But now > the ddr setting value is different with DMC, so if you enable the DMC, > system would crash in kernel. Correct the sdram setting here, according > to the requirements of kernel. > > [0] > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ > chromeos-3.14/drivers/clk/rockchip/clk-rk3288-dmc.c > > Signed-off-by: Chris Zhong > --- > > Changes in v2: > Modified into a more readable code style(Simon Glass) > > arch/arm/mach-rockchip/rk3288/sdram_rk3288.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] rockchip: make configure_emmc() empty for Firefly-RK3288
On 8 March 2016 at 11:46, Vagrant Cascadian wrote: > On 2016-03-05, FUKAUMI Naoki wrote: >> on v2016.03-rc3, size of SPL image compiled by gcc 5.3.0 is too large for >> Firefly-RK3288. (it's fine for Rock2) > ... >> to reduce size of SPL image, this patch makes configure_emmc() empty for >> Firefly-RK3288 as same as Rock2. >> >> Signed-off-by: FUKAUMI Naoki >> Acked-by: Simon Glass > > Fixed booting on my Firefly-RK3288. > > Tested-By: Vagrant Cascadian Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] rockchip: rk3288: correct sdram setting
On 10 March 2016 at 08:20, Simon Glass wrote: > On 6 March 2016 at 23:51, Chris Zhong wrote: >> The DMC driver in v3.14 kernel[0] get the ddr setting from PMU_SYS_REG2, >> and it expects uboot to store the value using a same protocol. But now >> the ddr setting value is different with DMC, so if you enable the DMC, >> system would crash in kernel. Correct the sdram setting here, according >> to the requirements of kernel. >> >> [0] >> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ >> chromeos-3.14/drivers/clk/rockchip/clk-rk3288-dmc.c >> >> Signed-off-by: Chris Zhong >> --- >> >> Changes in v2: >> Modified into a more readable code style(Simon Glass) >> >> arch/arm/mach-rockchip/rk3288/sdram_rk3288.c | 14 +++--- >> 1 file changed, 7 insertions(+), 7 deletions(-) > > Acked-by: Simon Glass Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: rk3036: change ddr frequency to 400M
On 17 February 2016 at 12:00, Simon Glass wrote: > On 17 February 2016 at 00:55, Jeffy Chen wrote: >> >> From: Lin Huang >> >> emac may use dpll as clock parent, and it request the clock frequency >> multiples of 50, so change ddr frequency to 400M. >> >> Signed-off-by: Lin Huang >> Signed-off-by: Jeffy Chen >> >> --- >> >> arch/arm/mach-rockchip/rk3036/sdram_rk3036.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > Acked-by: Simon Glass Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-rockchip
Hi Tom, A few last-minute fixes. The following changes since commit deff6fb3a7790e93264292982000275e78bb12e5: malloc: remove !gd handling (2016-03-08 15:01:47 -0500) are available in the git repository at: git://git.denx.de/u-boot-rockchip.git for you to fetch changes up to b5788dc0dd9570e98552833767f4373db965985d: rockchip: rk3288: correct sdram setting (2016-03-10 08:32:01 -0700) Chris Zhong (1): rockchip: rk3288: correct sdram setting FUKAUMI Naoki (1): rockchip: make configure_emmc() empty for Firefly-RK3288 Lin Huang (1): rockchip: rk3036: change ddr frequency to 400M arch/arm/mach-rockchip/rk3036/sdram_rk3036.c | 2 +- arch/arm/mach-rockchip/rk3288-board-spl.c| 2 +- arch/arm/mach-rockchip/rk3288/sdram_rk3288.c | 14 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Possible using U-boot to load FreeRTOS and How ?
Hello, Is it possible to use U-boot in order to load FreeRTOS operating system (or other OS like microCOS), and how ? Thank you very much for your help Best Regards *Mr Bertrand MERCIER* *Ingénieur-Architecte Logiciel Temps Réel - * *06 11 73 13 85* *Real Time Software Architect Engineer* *+33 6 11 73 13 85* ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: Add new command to regress USB devices
> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Thursday, March 10, 2016 3:09 AM
> To: Rajat Srivastava
> Cc: U-Boot Mailing List ; Marek Vašut ;
> Rajesh Bhagat
> Subject: Re: [PATCH] usb: Add new command to regress USB devices
>
> Hi Rajat,
>
> On 9 March 2016 at 04:22, Rajat Srivastava wrote:
> > This patch adds a new 'usb regress' command, that can be used to
> > regress test a USB device. It performs the following operations:
> >
> > 1. starts the USB device
> > 2. performs read/write operations
> > 3. stops the USB device
> > 4. verifies the contents of read/write operations
> >
> > Sample Output:
> > => usb regress 8100 8200 32m
> > regressing USB..
> > starting USB...
> > USB0: Register 200017f NbrPorts 2
> > Starting the controller
> > USB XHCI 1.00
> > scanning bus 0 for devices... 2 USB Device(s) found
> >scanning usb for storage devices... 1 Storage Device(s) found
> > USB write: device 0 block # 0, count 65536 ... 65536 blocks write: OK
> > USB read: device 0 block # 0, count 65536 ... 65536 blocks read: OK
> > stopping USB..
> > verifying data on addresses 0x8100 and 0x8200 Total of 65536
> > word(s) were the same
> >
> > Signed-off-by: Rajat Srivastava
> > Signed-off-by: Rajesh Bhagat
> > ---
> > common/cmd_usb.c | 174
> >
>
> ++-
> > 1 file changed, 173 insertions(+), 1 deletion(-)
>
> Can you rebase to mainline? This file has been renamed.
>
Will take care v2.
> >
> > diff --git a/common/cmd_usb.c b/common/cmd_usb.c index
> > a540b42..25fdeab 100644
> > --- a/common/cmd_usb.c
> > +++ b/common/cmd_usb.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #ifdef CONFIG_USB_STORAGE
> > static int usb_stor_curr_dev = -1; /* current device */ @@ -616,6
> > +617,167 @@ static int usb_device_info(void) } #endif
> >
> > +static unsigned long calc_blockcount(char * const size)
>
> Can you put this function in lib/display_options.c? I suggest something that
> decodes a
> string and returns a value (i.e. it would return 1024 for K, not 2, since
> that assumes a
> block size).
>
> The multiple check can go in cmd/usb.c
>
Will take care v2.
> > +{
> > + unsigned long value, multiplier;
> > + int size_len = strlen(size);
> > + char unit;
> > +
> > + /* extract the unit of size passed */
> > + unit = size[size_len - 1];
> > + /* updating the source string to remove unit */
> > + size[size_len - 1] = '\0';
> > +
> > + value = simple_strtoul(size, NULL, 10);
> > + if (value <= 0) {
> > + printf("invalid size\n");
> > + return 0;
> > + }
> > +
> > + if (unit == 'G' || unit == 'g') {
> > + multiplier = 2 * 1024 * 1024;
> > + } else if (unit == 'M' || unit == 'm') {
> > + multiplier = 2 * 1024;
> > + } else if (unit == 'K' || unit == 'k') {
> > + multiplier = 2;
> > + } else if (unit == 'B' || unit == 'b') {
> > + if (value % 512 != 0) {
> > + printf("size can only be multiples of 512 bytes\n");
> > + return 0;
> > + }
> > + multiplier = 1;
> > + value /= 512;
> > + } else {
> > + printf("syntax mismatch\n");
> > + return 0;
> > + }
> > +
> > + return value * multiplier;
> > +}
> > +
> > +static int usb_read_write_verify(unsigned long w_addr, unsigned long
> > r_addr,
> > + unsigned long
> > +cnt) {
> > + cmd_tbl_t *c;
> > + char str[3][16];
> > + char *ptr[4] = { "cmp", str[0], str[1], str[2] };
> > +
> > + c = find_cmd("cmp");
> > + if (!c) {
> > + printf("compare command not found\n");
> > + return -1;
> > + }
> > + printf("verifying data on addresses 0x%lx and 0x%lx\n", w_addr,
> > r_addr);
> > + sprintf(str[0], "%lx", w_addr);
> > + sprintf(str[1], "%lx", r_addr);
> > + sprintf(str[2], "%lx", cnt);
> > + (c->cmd)(c, 0, 4, ptr);
>
> We shouldn't call U-Boot functions via the command line parsing.
>
> Please can you refactor do_mem_cmp() to separate the command parsing from the
> memory comparison logic? Then you can call the latter directory.
>
AFAIU, we need to refactor do_mem_cmp to two functions and call mem_cmp
function
in our code. Please confirm.
> > + return 0;
> > +}
> > +
> > +
> > +static int do_usb_regress(int argc, char * const argv[])
>
> Would 'usb datatest' be a better name?
>
How about renaming the existing "usb test" command to "usb hwtest" as it
supports hardware
tests. And add the new proposed command as "usb test" ?
"usb test [dev] [port] [mode] - set USB 2.0 test mode\n"
"(specify port 0 to indicate the
[U-Boot] [PATCH 2/2 v2] driver/ddr/fsl: Add workaround for erratum A-009803
During initial DDR training, false parity errors may be detected.
This patch adds workaround to fix the erratum.
Tested on LS2085QDS and LS2080RDB.
Signed-off-by: Shengzhou Liu
---
v2: Integrated York's comments.
arch/arm/include/asm/arch-fsl-layerscape/config.h | 1 +
drivers/ddr/fsl/fsl_ddr_gen4.c| 44 ---
2 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 0ef7c9d..b0c112b 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -119,6 +119,7 @@
#define CONFIG_SYS_FSL_ERRATUM_A008751
#define CONFIG_SYS_FSL_ERRATUM_A009635
#define CONFIG_SYS_FSL_ERRATUM_A009663
+#define CONFIG_SYS_FSL_ERRATUM_A009803
#define CONFIG_SYS_FSL_ERRATUM_A009942
/* ARM A57 CORE ERRATA */
diff --git a/drivers/ddr/fsl/fsl_ddr_gen4.c b/drivers/ddr/fsl/fsl_ddr_gen4.c
index 6f76980..608810d 100644
--- a/drivers/ddr/fsl/fsl_ddr_gen4.c
+++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
@@ -12,7 +12,8 @@
#include
#include
-#ifdef CONFIG_SYS_FSL_ERRATUM_A008511
+#if defined(CONFIG_SYS_FSL_ERRATUM_A008511) | \
+ defined(CONFIG_SYS_FSL_ERRATUM_A009803)
static void set_wait_for_bits_clear(void *ptr, u32 value, u32 bits)
{
int timeout = 1000;
@@ -24,9 +25,9 @@ static void set_wait_for_bits_clear(void *ptr, u32 value, u32
bits)
timeout--;
}
if (timeout <= 0)
- puts("Error: A007865 wait for clear timeout.\n");
+ puts("Error: wait for clear timeout.\n");
}
-#endif /* CONFIG_SYS_FSL_ERRATUM_A008511 */
+#endif
#if (CONFIG_CHIP_SELECTS_PER_CTRL > 4)
#error Invalid setting for CONFIG_CHIP_SELECTS_PER_CTRL
@@ -201,7 +202,18 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t
*regs,
ddr_out32(&ddr->init_ext_addr, regs->ddr_init_ext_addr);
ddr_out32(&ddr->ddr_cdr2, regs->ddr_cdr2);
}
+
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009803
+ /* part 1 of 2 */
+ if (regs->ddr_sdram_cfg & SDRAM_CFG_RD_EN) { /* for RDIMM */
+ ddr_out32(&ddr->ddr_sdram_rcw_2,
+ regs->ddr_sdram_rcw_2 & ~0x0f00);
+ }
+
+ ddr_out32(&ddr->err_disable, regs->err_disable | DDR_ERR_DISABLE_APED);
+#else
ddr_out32(&ddr->err_disable, regs->err_disable);
+#endif
ddr_out32(&ddr->err_int_en, regs->err_int_en);
for (i = 0; i < 32; i++) {
if (regs->debug[i]) {
@@ -297,7 +309,8 @@ step2:
mb();
isb();
-#ifdef CONFIG_SYS_FSL_ERRATUM_A008511
+#if defined(CONFIG_SYS_FSL_ERRATUM_A008511) || \
+ defined(CONFIG_SYS_FSL_ERRATUM_A009803)
/* Part 2 of 2 */
/* This erraum only applies to verion 5.2.0 */
if (fsl_ddr_get_version(ctrl_num) == 0x50200) {
@@ -313,6 +326,7 @@ step2:
ctrl_num, ddr_in32(&ddr->debug[1]));
}
+#ifdef CONFIG_SYS_FSL_ERRATUM_A008511
/* The vref setting sequence is different for range 2 */
if (regs->ddr_cdr2 & DDR_CDR2_VREF_RANGE_2)
vref_seq = vref_seq2;
@@ -359,9 +373,29 @@ step2:
}
/* Restore D_INIT */
ddr_out32(&ddr->sdram_cfg_2, regs->ddr_sdram_cfg_2);
- }
#endif /* CONFIG_SYS_FSL_ERRATUM_A008511 */
+#ifdef CONFIG_SYS_FSL_ERRATUM_A009803
+ /* if it's RDIMM */
+ if (regs->ddr_sdram_cfg & SDRAM_CFG_RD_EN) {
+ for (i = 0; i < CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
+ if (!(regs->cs[i].config & SDRAM_CS_CONFIG_EN))
+ continue;
+ set_wait_for_bits_clear(&ddr->sdram_md_cntl,
+ MD_CNTL_MD_EN |
+ MD_CNTL_CS_SEL(i) |
+ 0x07ed,
+ MD_CNTL_MD_EN);
+ udelay(1);
+ }
+ }
+
+ ddr_out32(&ddr->err_disable,
+ regs->err_disable & ~DDR_ERR_DISABLE_APED);
+#endif
+ }
+#endif
+
total_gb_size_per_controller = 0;
for (i = 0; i < CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
if (!(regs->cs[i].config & 0x8000))
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v2] driver/ddr/fsl: Add address parity support for DDR4 UDIMM/discrete
Add support of address parity for DDR4 UDIMM or discrete memory.
It requires to configurate corresponding MR5[2:0] and TIMING_CFG_7[PAR_LAT].
Parity can be turned on/off by hwconfig, e.g. hwconfig=fsl_ddr:parity=on.
Signed-off-by: Shengzhou Liu
---
v2: Integrated York's comments.
doc/README.fsl-ddr | 9
drivers/ddr/fsl/ctrl_regs.c | 55 -
drivers/ddr/fsl/options.c | 15 +++--
include/fsl_ddr_sdram.h | 11 -
4 files changed, 82 insertions(+), 8 deletions(-)
diff --git a/doc/README.fsl-ddr b/doc/README.fsl-ddr
index cd71ec8..cec5d94 100644
--- a/doc/README.fsl-ddr
+++ b/doc/README.fsl-ddr
@@ -123,6 +123,14 @@ ECC can be turned on/off by hwconfig.
Syntax is
hwconfig=fsl_ddr:ecc=off
+
+Memory address parity on/off
+
+address parity can be turned on/off by hwconfig.
+Syntax is:
+hwconfig=fsl_ddr:parity=on
+
+
Memory testing options for mpc85xx
==
1. Memory test can be done once U-Boot prompt comes up using mtest, or
@@ -143,6 +151,7 @@ platform
hwconfig=fsl_ddr:addr_hash=true,ctlr_intlv=cacheline,bank_intlv=cs0_cs1_cs2_cs3,ecc=on
+
Table for dynamic ODT for DDR3
==
For single-slot system with quad-rank DIMM and dual-slot system, dynamic ODT
may
diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index 0bfcd34..9073917 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -895,11 +895,15 @@ static void set_ddr_sdram_cfg_2(const unsigned int
ctrl_num,
slow = get_ddr_freq(ctrl_num) < 124900;
#endif
- if (popts->registered_dimm_en) {
+ if (popts->registered_dimm_en)
rcw_en = 1;
- ap_en = popts->ap_en;
- } else {
+
+ /* DDR4 can have address parity for UDIMM and discrete */
+ if ((CONFIG_FSL_SDRAM_TYPE != SDRAM_TYPE_DDR4) &&
+ (!popts->registered_dimm_en)) {
ap_en = 0;
+ } else {
+ ap_en = popts->ap_en;
}
x4_en = popts->x4_en ? 1 : 0;
@@ -1135,6 +1139,7 @@ static void set_ddr_sdram_mode_9(fsl_ddr_cfg_regs_t *ddr,
unsigned short esdmode5;/* Extended SDRAM mode 5 */
int rtt_park = 0;
bool four_cs = false;
+ const unsigned int mclk_ps = get_memory_clk_period_ps(0);
#if CONFIG_CHIP_SELECTS_PER_CTRL == 4
if ((ddr->cs[0].config & SDRAM_CS_CONFIG_EN) &&
@@ -1150,6 +1155,19 @@ static void set_ddr_sdram_mode_9(fsl_ddr_cfg_regs_t *ddr,
esdmode5 = 0x0400; /* Data mask enabled */
}
+ /* set command/address parity latency */
+ if (ddr->ddr_sdram_cfg_2 & SDRAM_CFG2_AP_EN) {
+ if (mclk_ps >= 935) {
+ /* for DDR4-1600/1866/2133 */
+ esdmode5 |= DDR_MR5_CA_PARITY_LAT_4_CLK;
+ } else if (mclk_ps >= 833) {
+ /* for DDR4-2400 */
+ esdmode5 |= DDR_MR5_CA_PARITY_LAT_5_CLK;
+ } else {
+ printf("parity: mclk_ps = %d not supported\n", mclk_ps);
+ }
+ }
+
ddr->ddr_sdram_mode_9 = (0
| ((esdmode4 & 0x) << 16)
| ((esdmode5 & 0x) << 0)
@@ -1170,6 +1188,20 @@ static void set_ddr_sdram_mode_9(fsl_ddr_cfg_regs_t *ddr,
} else {
esdmode5 = 0x0400;
}
+
+ if (ddr->ddr_sdram_cfg_2 & SDRAM_CFG2_AP_EN) {
+ if (mclk_ps >= 935) {
+ /* for DDR4-1600/1866/2133 */
+ esdmode5 |= DDR_MR5_CA_PARITY_LAT_4_CLK;
+ } else if (mclk_ps >= 833) {
+ /* for DDR4-2400 */
+ esdmode5 |= DDR_MR5_CA_PARITY_LAT_5_CLK;
+ } else {
+ printf("parity: mclk_ps = %d not
supported\n",
+ mclk_ps);
+ }
+ }
+
switch (i) {
case 1:
ddr->ddr_sdram_mode_11 = (0
@@ -1925,12 +1957,25 @@ static void set_timing_cfg_7(const unsigned int
ctrl_num,
const common_timing_params_t *common_dimm)
{
unsigned int txpr, tcksre, tcksrx;
- unsigned int cke_rst, cksre, cksrx, par_lat, cs_to_cmd;
+ unsigned int cke_rst, cksre, cksrx, par_lat = 0, cs_to_cmd;
+ const unsigned int mclk_ps = get_memory_clk_period_ps(ctrl_num);
txpr = max(5U, picos_to_mclk(ctrl_num, common_dimm->trfc1_ps + 1));
tcksre = max(5U, picos_to_mclk(ctrl_num, 1));
tcksrx = max(5U, picos_to
[U-Boot] [PATCH 3/6] usb: Remove 1 second per port timeout in usb_hub_configure()
On complex USB infrastructures, with many hubs and therefore many (perhaps unconnected) ports, current U-Boot has a very long USB scanning time. On my current custom x86 board, this time is over 20 seconds!!! One of the biggest problems here is a 1 second delay (timeout) in usb_hub_configure() to check, if a USB device is connected to a port. As this is done for each port, this timeout sums up over all unconnected ports. This patch removes this 1 seconds per port timeout from usb_hub_configure(). All my USB devices are still detected correctly on my platform. And I'm using 4 different USB keys right now. Including a problematic "Intenso Alu Line" key. Here the numbers for my current board: Without this patch: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 24.811 seconds With this patch: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 10.822 seconds So ~14 seconds of USB scanning time reduction. Again, this timeout is only removed if CONFIG_USB_FAST_SCAN is defined. Once more tests are done on multiple other platforms we can decide to remove this timeout completely. Signed-off-by: Stefan Roese Cc: Simon Glass Cc: Hans de Goede Cc: Stephen Warren Cc: Marek Vasut --- common/usb_hub.c | 4 1 file changed, 4 insertions(+) diff --git a/common/usb_hub.c b/common/usb_hub.c index 660f4f4..780291f 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -478,7 +478,11 @@ static int usb_hub_configure(struct usb_device *dev) unsigned short portstatus, portchange; int ret; ulong start = get_timer(0); +#if defined(CONFIG_USB_FAST_SCAN) + uint delay = 0; +#else uint delay = CONFIG_SYS_HZ; +#endif #ifdef CONFIG_SANDBOX if (state_get_skip_delays()) -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/6] usb: Reduce USB scanning time
My current x86 platform (Bay Trail, not in mainline yet) has a quite complex USB infrastructure with many USB hubs. Here the USB scan takes an incredible huge amount of time: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 28.415 seconds This is of course not acceptable on platforms, where USB needs to get scanned at every bootup. As this increases the bootup time of this device by nearly 30 seconds! This patch series greatly reduces the USB scanning time. This is done by multiple means: - Remove or reduce delays and timeouts - Remove a 2nd reset of the USB hubs - Introduce a static USB configuration method to skip specific USB ports while scanning Even without the new static configuration (which can disable specified ports), the resulting USB scanning time is greatly reduced: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 3.777 seconds As you can see, the time is reduced from 28.4 to 3.8 seconds! And with the static configuration, which can disable specific ports, the time can be reduced even further. Please find more details to the changes in the patch description. This patch introduces the new configuration option CONFIG_USB_FAST_SCAN to enable most of the speed enhancements. I'm actually not sure, if we should introduce this config option at all. Or better unconditionally apply all these changes to make this speedup default for all boards. As this could break some USB configurations, it needs thorough testing on many platforms before it becomes the default configuration. Testing and comments welcome! Thanks, Stefan Stefan Roese (6): usb: legacy_hub_port_reset(): Speedup hub reset handling usb: Remove 200 ms delay in usb_hub_port_connect_change() usb: Remove 1 second per port timeout in usb_hub_configure() usb: usb_hub_power_on(): Use 100ms power-on delay instead of 1 sec (optionally) usb: Don't reset the USB hub a 2nd time usb: Implement static USB port configuration to speed up USB scanning common/usb.c | 6 ++ common/usb_hub.c | 65 ++-- 2 files changed, 69 insertions(+), 2 deletions(-) -- 2.7.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/6] usb: Implement static USB port configuration to speed up USB scanning
This patch implements an optionally quasi static USB port configuration.
This is done by using an environment variable, that describes the ports
that shall be scanned at the next USB scans (usb start, usb reset).
The "usb_port_use" env variable is used to describe this static USB
configuration. For this, each USB hub is represented by a 8-bit value.
Making it possible to configure a maximum of 8 ports for each USB hub.
A 64-bit representation is used, therefore 8 USB hubs can be described
in total.
Here an example for this "usb_port_use" environment variable:
usb_port_use = 00040301
---
1st USB hub: 0x01 -> Use port 1 (first port)
2nd USB hub: 0x03 -> Use port 1 and 2
3rd USB hub: 0x04 -> Use port 3
4th USB hub: 0x00 -> Use no ports
...
8th USB hub: 0x00 -> Use no ports
To make this procedure of configuring this env variable less error prone
and less painful, this patch also introduces another env variable that
is dynamically generated at each USB scan: "usb_port_detected". This
variable is similar to "usb_port_use". It has a bit enabled for each
port that has been detected. This can be easily used on a new system,
where the USB configuration is static in this way:
Run the USB scan (usb start, usb reset) without the "usb_port_use"
variable set. This will result in all ports being scanned and the result
written into the "usb_port_detected" variable. To configure the USB
subsystem to only scan these specific USB ports upon the next
scans, you only need to write the value from "usb_port_detected"
into the "usb_port_use" variable:
=> setenv usb_port_use ${usb_port_detected}
=> saveenv
The next scans will only scan those enabled ports.
Its of course also possible to manually "tune" this env variable. If
some ports are not needed in U-Boot, they can be disabled this way.
This will result in less USB hub ports getting scanned and therefore
in a faster USB scan time. Here an example:
With all USB devices enabled (usb_port_use not set):
=> setenv usb_port_use
=> time usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 3.776 seconds
=> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 0mA)
|
+-8 Mass Storage (480 Mb/s, 200mA)
|6989 Intenso Alu Line EE706F5E
|
+-9 Mass Storage (480 Mb/s, 200mA)
|JetFlash Mass Storage Device 3281440601
|
+-3 Hub (480 Mb/s, 100mA)
| |
| +-4 Hub (12 Mb/s, 100mA)
|
+-5 Hub (480 Mb/s, 0mA)
|
+-6 Mass Storage (480 Mb/s, 200mA)
|Kingston DataTraveler 2.0 50E549C688C4BE7189942766
|
+-7 Mass Storage (480 Mb/s, 98mA)
USBest Technology USB Mass Storage Device 09092207fbf0c4
=> printenv usb_port_detected
usb_port_detected=000501080f01
With only some USB devices enabled:
=> setenv usb_port_use 0c01
=> time usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
time: 1.354 seconds
=> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 0mA)
|
+-3 Mass Storage (480 Mb/s, 200mA)
|6989 Intenso Alu Line EE706F5E
|
+-4 Mass Storage (480 Mb/s, 200mA)
JetFlash Mass Storage Device 3281440601
So this feature of USB port enabling via environment variable is very
helpful to further reduce the USB scanning time in some configurations.
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Hans de Goede
Cc: Stephen Warren
Cc: Marek Vasut
---
common/usb_hub.c | 44
1 file changed, 44 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index d5fcd27..b600cfa 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -353,6 +353,10 @@ static int usb_hub_configure(struct usb_device *dev)
struct usb_hub_descriptor *descriptor;
struct usb_hub_device *hub;
__maybe_unused struct usb_hub_status *hubsts;
+ static u64 port_active;
+ u32 port_use = 0xff;/* Default: use all ports */
+ const char *env;
+ char str[18];
int ret;
/* "allocate" Hub device */
@@ -477,6 +481,18 @@ static int usb_hub_configure(struct usb_device *dev)
for (i = 0; i < dev->maxchild; i++)
usb_hub_reset_devices(i + 1);
+ /* Check if only configured ports shall be scanned / enabled */
+ env = getenv("usb_port_use");
+ if (env) {
+ port_use = (simple_strtoull(env, NULL, 16) >>
+ ((dev->devnum - 1) * 8)) & 0xff;
+ debug("port_usb[%d]=0x%02x\n", dev->devnum, port_use);
+ }
+
+ /* Reset port_active variable on the scan of the 1st USB hub */
+ if (dev->devnum == 1)
+ port_active = 0;
+
for (i = 0; i < dev->maxchild; i++) {
ALLOC_CACHE_ALIGN_BUFFER(struct us
[U-Boot] [PATCH 2/6] usb: Remove 200 ms delay in usb_hub_port_connect_change()
This patch removes 2 mdelay(200) calls from usb_hub_port_connect_change().
These delays don't seem to be necessary. At least not in my tests. Here
the number for a custom x86 Bay Trail board (not in mainline yet) with
a quite large and complex USB hub infrastructure.
Without this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 28.415 seconds
With this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 24.811 seconds
So ~3.5 seconds of USB scanning time reduction.
These mdelay calls are removed if CONFIG_USB_FAST_SCAN is defined. They
are not removed per default yet. It would be good to test with this
option enabled on many other boards. And once we have a good testing
base we can decide to remove these delays completely, including this
macro.
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Hans de Goede
Cc: Stephen Warren
Cc: Marek Vasut
---
common/usb_hub.c | 4
1 file changed, 4 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 10fdd3c..660f4f4 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -275,7 +275,9 @@ int usb_hub_port_connect_change(struct usb_device *dev, int
port)
if (!(portstatus & USB_PORT_STAT_CONNECTION))
return -ENOTCONN;
}
+#if !defined(CONFIG_USB_FAST_SCAN)
mdelay(200);
+#endif
/* Reset the port */
ret = legacy_hub_port_reset(dev, port, &portstatus);
@@ -285,7 +287,9 @@ int usb_hub_port_connect_change(struct usb_device *dev, int
port)
return ret;
}
+#if !defined(CONFIG_USB_FAST_SCAN)
mdelay(200);
+#endif
switch (portstatus & USB_PORT_STAT_SPEED_MASK) {
case USB_PORT_STAT_SUPER_SPEED:
--
2.7.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/6] usb: legacy_hub_port_reset(): Speedup hub reset handling
Start with a short USB hub reset delay of 10ms. This can be enough for
some configurations.
The 2nd delay at the of the loop is completely removed. Since the delay
hasn't been long enough, a longer delay time of 200ms is assigned. And
will be used in the next loop round.
This hub reset handling is also used in the v4.4 Linux USB driver,
hub_port_reset().
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Hans de Goede
Cc: Stephen Warren
Cc: Marek Vasut
---
common/usb_hub.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index e1de813..10fdd3c 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -46,6 +46,9 @@ DECLARE_GLOBAL_DATA_PTR;
#define USB_BUFSIZ 512
+#define HUB_SHORT_RESET_TIME 10
+#define HUB_LONG_RESET_TIME200
+
/* TODO(s...@chromium.org): Remove this when CONFIG_DM_USB is defined */
static struct usb_hub_device hub_dev[USB_MAX_HUB];
static int usb_hub_index;
@@ -164,6 +167,7 @@ int legacy_hub_port_reset(struct usb_device *dev, int port,
int err, tries;
ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);
unsigned short portstatus, portchange;
+ int delay = HUB_SHORT_RESET_TIME; /* start with short reset delay */
#ifdef CONFIG_DM_USB
debug("%s: resetting '%s' port %d...\n", __func__, dev->dev->name,
@@ -176,7 +180,7 @@ int legacy_hub_port_reset(struct usb_device *dev, int port,
if (err < 0)
return err;
- mdelay(200);
+ mdelay(delay);
if (usb_get_port_status(dev, port + 1, portsts) < 0) {
debug("get_port_status failed status %lX\n",
@@ -215,7 +219,8 @@ int legacy_hub_port_reset(struct usb_device *dev, int port,
if (portstatus & USB_PORT_STAT_ENABLE)
break;
- mdelay(200);
+ /* Switch to long reset delay for the next round */
+ delay = HUB_LONG_RESET_TIME;
}
if (tries == MAX_TRIES) {
--
2.7.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] usb: usb_hub_power_on(): Use 100ms power-on delay instead of 1 sec (optionally)
In a system with a complex USB infrastrcture (many USB hubs), the
power-on delay of mininimum 1 second for each USB hub results in a quite
big USB scanning time. Many USB devices can deal with much lower
power-on delays. In my test system, even 10ms seems to be enough
for the USB device to get detected correctly. This patch now
reduces the minimum 1 second delay to a minumum of 100ms instead.
This results in a big USB scan time reduction:
Here the numbers for my current board:
Without this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 10.822 seconds
With this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 6.319 seconds
So ~4.5 seconds of USB scanning time reduction.
I'm not really sure if this patch can be accepted in general as is.
In patch 0d437bca [usb: hub: fix power good delay timing] by Stephen
Warren, this delay was changes according to "Connect Timing ECN.pdf"
to a total of 1 second plus the hub port's power good time. Now its
changes back to 100ms which is a violation of this spec. But still,
for most USB devices this 100ms is more than enough. So its a valid
use-case to lower this time in special (perhaps static) USB
environments.
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Hans de Goede
Cc: Stephen Warren
Cc: Marek Vasut
---
common/usb_hub.c | 4
1 file changed, 4 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 780291f..d5fcd27 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -120,7 +120,11 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
pgood_delay = max(pgood_delay,
(unsigned)simple_strtol(env, NULL, 0));
debug("pgood_delay=%dms\n", pgood_delay);
+#if defined(CONFIG_USB_FAST_SCAN)
+ mdelay(pgood_delay + 100);
+#else
mdelay(pgood_delay + 1000);
+#endif
}
void usb_hub_reset(void)
--
2.7.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/6] usb: Don't reset the USB hub a 2nd time
Debugging has shown, that all USB hubs are being resetted twice while
USB scanning. This introduces additional delays and makes USB scanning
even more slow. Testing has shown that this 2nd USB hub reset doesn't
seem to be necessary.
This patch now removes this 2nd USB hub reset if CONFIG_USB_FAST_SCAN
is defined. Resulting in faster USB scan time. Here the current
number:
Without this patch:
=> time usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 6.319 seconds
With this patch:
=> time usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 3.777 seconds
So ~2.5 seconds of USB scanning time reduction.
Again, this 2nd reset is only removed if CONFIG_USB_FAST_SCAN is
defined. Once more tests are done on multiple other platforms we
can decide to remove this 2nd reset completely.
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Hans de Goede
Cc: Stephen Warren
Cc: Marek Vasut
---
common/usb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index c7b8b0e..b96a2f6 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -920,6 +920,11 @@ __weak int usb_alloc_device(struct usb_device *udev)
static int usb_hub_port_reset(struct usb_device *dev, struct usb_device *hub)
{
if (hub) {
+#if !defined(CONFIG_USB_FAST_SCAN)
+ /*
+* Is this 2nd hub port reset necessary? The port has already
+* been reset in usb_hub_port_connect_change() before.
+*/
unsigned short portstatus;
int err;
@@ -929,6 +934,7 @@ static int usb_hub_port_reset(struct usb_device *dev,
struct usb_device *hub)
printf("\n Couldn't reset port %i\n", dev->portnr);
return err;
}
+#endif
} else {
usb_reset_root_port(dev);
}
--
2.7.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-rockchip
On Thu, Mar 10, 2016 at 08:41:57AM -0700, Simon Glass wrote: > Hi Tom, > > A few last-minute fixes. > > The following changes since commit deff6fb3a7790e93264292982000275e78bb12e5: > > malloc: remove !gd handling (2016-03-08 15:01:47 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-rockchip.git > > for you to fetch changes up to b5788dc0dd9570e98552833767f4373db965985d: > > rockchip: rk3288: correct sdram setting (2016-03-10 08:32:01 -0700) > 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] [GIT PULL] u-boot-mips/master
On Wed, Mar 09, 2016 at 12:01:35PM +0100, Daniel Schwierzeck wrote: > Hi Tom, > > two fixes for MIPS: > - fix a build error on Travis CI for pic32mzdask board > - fix cache op for toolchains not supporting __builtin_mips_cache() > > please consider pulling, thanks > > > The following changes since commit deff6fb3a7790e93264292982000275e78bb12e5: > > malloc: remove !gd handling (2016-03-08 15:01:47 -0500) > > are available in the git repository at: > > git://git.denx.de/u-boot-mips.git master > > for you to fetch changes up to 40a09be2e925e6e4b56a236fec5aed2c002e9d6f: > > MIPS: pic32mzdask: use CONFIG_USE_PRIVATE_LIBGCC=y (2016-03-09 11:54:01 > +0100) > 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 v2] exynos: Set CNTFRQ
On 03/10/2016 05:18 AM, Alexander Graf wrote: > Commit 73a1cb27 moved the check whether we should set the architected > timer frequency from CONFIG_SYS_CLK_FREQ to CONFIG_TIMER_CLK_FREQ, but > did not update all users of it. > > The one where I (finally) realized why KVM didn't work is the Arndale > board, so this patch adds the respective define to it. > > Signed-off-by: Alexander Graf > Fixes: 73a1cb27 > > --- > > v1 -> v2: > > - Map to CONFIG_SYS_CLK_FREQ instead of redefining to the same number > --- > include/configs/exynos-common.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/configs/exynos-common.h b/include/configs/exynos-common.h > index 852829c..b61f889 100644 > --- a/include/configs/exynos-common.h > +++ b/include/configs/exynos-common.h > @@ -31,6 +31,7 @@ > > /* input clock of PLL: 24MHz input clock */ > #define CONFIG_SYS_CLK_FREQ 2400 > +#define CONFIG_TIMER_CLK_FREQCONFIG_SYS_CLK_FREQ > > #define CONFIG_SETUP_MEMORY_TAGS > #define CONFIG_CMDLINE_TAG > Reviewed-by: York Sun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] exynos: Set CNTFRQ
On 03/10/2016 05:18 AM, Alexander Graf wrote: > Commit 73a1cb27 moved the check whether we should set the architected > timer frequency from CONFIG_SYS_CLK_FREQ to CONFIG_TIMER_CLK_FREQ, but > did not update all users of it. > > The one where I (finally) realized why KVM didn't work is the Arndale > board, so this patch adds the respective define to it. > > Signed-off-by: Alexander Graf > Fixes: 73a1cb27 > > --- > > v1 -> v2: > > - Map to CONFIG_SYS_CLK_FREQ instead of redefining to the same number > --- > include/configs/exynos-common.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/configs/exynos-common.h b/include/configs/exynos-common.h > index 852829c..b61f889 100644 > --- a/include/configs/exynos-common.h > +++ b/include/configs/exynos-common.h > @@ -31,6 +31,7 @@ > > /* input clock of PLL: 24MHz input clock */ > #define CONFIG_SYS_CLK_FREQ 2400 > +#define CONFIG_TIMER_CLK_FREQCONFIG_SYS_CLK_FREQ > > #define CONFIG_SETUP_MEMORY_TAGS > #define CONFIG_CMDLINE_TAG > This makes sense. Xiubo, Can you take another look to make sure nothing else is missed? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5 v6] armv8: ls2080a: remove obsolete stream ID partitioning support
From: Stuart Yoder
Remove stream ID partitioning support that has been made
obsolete by upstream device tree bindings that specify how
representing how PCI requester IDs are mapped to MSI specifiers
and SMMU stream IDs.
Signed-off-by: Stuart Yoder
---
-v6: no changes
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 113 ---
drivers/pci/pcie_layerscape.c | 70 ---
2 files changed, 183 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 4e4861d..7a64f41 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -70,115 +70,6 @@ void ft_fixup_cpu(void *blob)
}
#endif
-/*
- * the burden is on the the caller to not request a count
- * exceeding the bounds of the stream_ids[] array
- */
-void alloc_stream_ids(int start_id, int count, u32 *stream_ids, int max_cnt)
-{
- int i;
-
- if (count > max_cnt) {
- printf("\n%s: ERROR: max per-device stream ID count exceed\n",
- __func__);
- return;
- }
-
- for (i = 0; i < count; i++)
- stream_ids[i] = start_id++;
-}
-
-/*
- * This function updates the mmu-masters property on the SMMU
- * node as per the SMMU binding-- phandle and list of stream IDs
- * for each MMU master.
- */
-void append_mmu_masters(void *blob, const char *smmu_path,
- const char *master_name, u32 *stream_ids, int count)
-{
- u32 phandle;
- int smmu_nodeoffset;
- int master_nodeoffset;
- int i;
-
- /* get phandle of mmu master device */
- master_nodeoffset = fdt_path_offset(blob, master_name);
- if (master_nodeoffset < 0) {
- printf("\n%s: ERROR: master not found\n", __func__);
- return;
- }
- phandle = fdt_get_phandle(blob, master_nodeoffset);
- if (!phandle) { /* if master has no phandle, create one */
- phandle = fdt_create_phandle(blob, master_nodeoffset);
- if (!phandle) {
- printf("\n%s: ERROR: unable to create phandle\n",
- __func__);
- return;
- }
- }
-
- /* append it to mmu-masters */
- smmu_nodeoffset = fdt_path_offset(blob, smmu_path);
- if (fdt_appendprop_u32(blob, smmu_nodeoffset, "mmu-masters",
- phandle) < 0) {
- printf("\n%s: ERROR: unable to update SMMU node\n", __func__);
- return;
- }
-
- /* for each stream ID, append to mmu-masters */
- for (i = 0; i < count; i++) {
- fdt_appendprop_u32(blob, smmu_nodeoffset, "mmu-masters",
- stream_ids[i]);
- }
-
- /* fix up #stream-id-cells with stream ID count */
- if (fdt_setprop_u32(blob, master_nodeoffset, "#stream-id-cells",
- count) < 0)
- printf("\n%s: ERROR: unable to update #stream-id-cells\n",
- __func__);
-}
-
-
-/*
- * The info below summarizes how streamID partitioning works
- * for ls2080a and how it is conveyed to the OS via the device tree.
- *
- * -non-PCI legacy, platform devices (USB, SD/MMC, SATA, DMA)
- * -all legacy devices get a unique ICID assigned and programmed in
- * their AMQR registers by u-boot
- * -u-boot updates the hardware device tree with streamID properties
- * for each platform/legacy device (smmu-masters property)
- *
- * -PCIe
- * -for each PCI controller that is active (as per RCW settings),
- * u-boot will allocate a range of ICID and convey that to Linux via
- * the device tree (smmu-masters property)
- *
- * -DPAA2
- * -u-boot will allocate a range of ICIDs to be used by the Management
- * Complex for containers and will set these values in the MC DPC image.
- * -the MC is responsible for allocating and setting up ICIDs
- * for all DPAA2 devices.
- *
- */
-#ifdef CONFIG_FSL_LSCH3
-static void fdt_fixup_smmu(void *blob)
-{
- int nodeoffset;
-
- nodeoffset = fdt_path_offset(blob, "/iommu@500");
- if (nodeoffset < 0) {
- printf("\n%s: WARNING: no SMMU node found\n", __func__);
- return;
- }
-
- /* fixup for all PCI controllers */
-#ifdef CONFIG_PCI
- fdt_fixup_smmu_pcie(blob);
-#endif
-}
-#endif
-
void ft_cpu_setup(void *blob, bd_t *bd)
{
#ifdef CONFIG_MP
@@ -200,8 +91,4 @@ void ft_cpu_setup(void *blob, bd_t *bd)
#ifdef CONFIG_FSL_ESDHC
fdt_fixup_esdhc(blob, bd);
#endif
-
-#ifdef CONFIG_FSL_LSCH3
- fdt_fixup_smmu(blob);
-#endif
}
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 99f9c83..bb29222 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -664,73 +664,3 @@ void ft_pci_setup(void *blob, bd_t *bd)
{
}
#endif
-
-
[U-Boot] [PATCH 0/5 v6] support mapping PCI device ids to stream ids for MSIs
From: Stuart Yoder A binding for PCI nodes has been finalized specifying how PCI device IDs can be mapped to MSI specifiers. See Documentation/devicetree/bindings/pci/pci-msi.txt in the kernel. For ls2080a and similar Layerscape SoCs, the MSI specifier is the stream id. A programmable table (LUT) in the PCI controller defines the hardware mapping of PCI requester IDs to stream IDs. This patch series implements support for this mapping. Version 6 of the series squashes patches 4-7 together to avoid static functions defined but not used. This results in 5 patches: Patch 1 removes the obsolete available-stream-id support. Patch 2 updates stream ID partitioning info to be current Patch 3 updates pci.h so pci_get_hose_head() is available Patch 4 defines LUT register offsets Patch 5 implements a function to iterate over all PCI buses and set up a LUT entry and msi-map for all discovered devices. Helper functions allocate LUT entries, streamIDs, and append msi-map entries. This patch series enables MSIs on ls2080a on v4.5-rc5 and later kernels. The obsolete support removed was unused in any upstream kernels. -v2 changes -in patch 7 removed skip of the host bridge when scanning the bus -v3 changes -patch 4: moved LUT #defines to immap_lsch3.h, made index allocator return an int -patch 5: return 0x on error -patch 7: fixed return value checks -v4 changes -put all device ID to stream ID mapping under LS2 #ifdefs -v5 changes -check CONFIG_FSL_LSCH3 instead of SoC specific defines -v6 changes -squashed patches 4-7 together, split out LUT #defines into separate patch, replaced a remaining SoC define with CONFIG_FSL_LSCH3 Stuart Yoder (5): armv8: ls2080a: remove obsolete stream ID partitioning support armv8: ls2080a: update stream ID partitioning info pci: make pci_get_hose_head() available to external users pci/layerscape: add defines for LUT pci/layerscape: set LUT and msi-map for discovered PCI devices arch/arm/cpu/armv8/fsl-layerscape/fdt.c| 113 -- .../include/asm/arch-fsl-layerscape/immap_lsch3.h |4 + .../asm/arch-fsl-layerscape/ls2080a_stream_id.h| 55 +++-- drivers/pci/pcie_layerscape.c | 217 +--- include/pci.h |1 + 5 files changed, 186 insertions(+), 204 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5 v6] armv8: ls2080a: update stream ID partitioning info
From: Stuart Yoder -update comments around how stream IDs are partitioned -stream IDs allocated to PCI are no longer divided up by controller, but are instead a contiguous range Signed-off-by: Stuart Yoder --- -v6: no changes .../asm/arch-fsl-layerscape/ls2080a_stream_id.h| 55 1 file changed, 34 insertions(+), 21 deletions(-) diff --git a/arch/arm/include/asm/arch-fsl-layerscape/ls2080a_stream_id.h b/arch/arm/include/asm/arch-fsl-layerscape/ls2080a_stream_id.h index 954104b..ee28323 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/ls2080a_stream_id.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/ls2080a_stream_id.h @@ -7,28 +7,48 @@ #ifndef __FSL_STREAM_ID_H #define __FSL_STREAM_ID_H -/* Stream IDs on ls2080a devices are not hardwired and are +/* + * Stream IDs on ls2080a devices are not hardwired and are * programmed by sw. There are a limited number of stream IDs * available, and the partitioning of them is scenario dependent. * This header defines the partitioning between legacy, PCI, * and DPAA2 devices. * - * This partitiong can be customized in this file depending - * on the specific hardware config-- e.g. perhaps not all - * PEX controllers are in use. + * This partitioning can be customized in this file depending + * on the specific hardware config: + * + * -non-PCI legacy, platform devices (USB, SD/MMC, SATA, DMA) + * -all legacy devices get a unique stream ID assigned and programmed in + * their AMQR registers by u-boot + * + * -PCIe + * -there is a range of stream IDs set aside for PCI in this + * file. U-boot will scan the PCI bus and for each device discovered: + * -allocate a streamID + * -set a PEXn LUT table entry mapping 'requester ID' to 'stream ID' + * -set a msi-map entry in the PEXn controller node in the + * device tree (see Documentation/devicetree/bindings/pci/pci-msi.txt + * for more info on the msi-map definition) * - * On LS2080 stream IDs are programmed in AMQ registers (32-bits) for + * -DPAA2 + * -u-boot will allocate a range of stream IDs to be used by the Management + * Complex for containers and will set these values in the MC DPC image. + * -the MC is responsible for allocating and setting up 'isolation context + * IDs (ICIDs) based on the allocated stream IDs for all DPAA2 devices. + * + * On ls2080a SoCs stream IDs are programmed in AMQ registers (32-bits) for * each of the different bus masters. The relationship between * the AMQ registers and stream IDs is defined in the table below: * AMQ bitstreamID bit * --- - * PL[18] 9 - * BMT[17] 8 - * VA[16] 7 - * [15] - - * ICID[14:7] - - * ICID[6:0]6-0 + * PL[18] 9// privilege bit + * BMT[17] 8// bypass translation + * VA[16] 7// reserved + * [15] -// unused + * ICID[14:7] -// unused + * ICID[6:0]6-0 // isolation context id * + * */ #define AMQ_PL_MASK(0x1 << 18) /* priviledge bit */ @@ -46,16 +66,9 @@ #define FSL_SATA2_STREAM_ID5 #define FSL_DMA_STREAM_ID 6 -/* PCI - programmed in PEXn_LUT by OS */ -/* 4 IDs per controller */ -#define FSL_PEX1_STREAM_ID_START 7 -#define FSL_PEX1_STREAM_ID_END 10 -#define FSL_PEX2_STREAM_ID_START 11 -#define FSL_PEX2_STREAM_ID_END 14 -#define FSL_PEX3_STREAM_ID_START 15 -#define FSL_PEX3_STREAM_ID_END 18 -#define FSL_PEX4_STREAM_ID_START 19 -#define FSL_PEX4_STREAM_ID_END 22 +/* PCI - programmed in PEXn_LUT */ +#define FSL_PEX_STREAM_ID_START7 +#define FSL_PEX_STREAM_ID_END 22 /* DPAA2 - set in MC DPC and alloced by MC */ #define FSL_DPAA2_STREAM_ID_START 23 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5 v6] pci: make pci_get_hose_head() available to external users
From: Stuart Yoder put pci_get_hose_head() prototype in header so it is available to external users-- allowing them to find and iterate over all pci controllers Signed-off-by: Stuart Yoder --- -v6: no changes include/pci.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/pci.h b/include/pci.h index 68548b0..8698056 100644 --- a/include/pci.h +++ b/include/pci.h @@ -700,6 +700,7 @@ extern void *pci_map_bar(pci_dev_t pdev, int bar, int flags); extern void pci_register_hose(struct pci_controller* hose); extern struct pci_controller* pci_bus_to_hose(int bus); extern struct pci_controller *find_hose_by_cfg_addr(void *cfg_addr); +extern struct pci_controller *pci_get_hose_head(void); extern int pci_skip_dev(struct pci_controller *hose, pci_dev_t dev); extern int pci_hose_scan(struct pci_controller *hose); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5 v6] pci/layerscape: set LUT and msi-map for discovered PCI devices
From: Stuart Yoder
msi-map properties are used to tell an OS how PCI requester IDs are
mapped to ARM SMMU stream IDs.
for all PCI devices discovered in a system:
-allocate a LUT (look-up-table) entry in that PCI controller
-allocate a stream ID for the device
-program and enable a LUT entry (maps PCI requester id to stream ID)
-set the msi-map property on the controller reflecting the
LUT mapping
basic bus scanning loop/logic was taken from drivers/pci/pci.c
pci_hose_scan_bus().
Signed-off-by: Stuart Yoder
---
-v6: squashed lut, stream id, and msi-map helper functions
(previously patches 4-6) into this patch
drivers/pci/pcie_layerscape.c | 147 +
1 file changed, 147 insertions(+)
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index bb29222..0ba960e 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -93,6 +93,7 @@ struct ls_pcie {
void __iomem *dbi;
void __iomem *va_cfg0;
void __iomem *va_cfg1;
+ int next_lut_index;
struct pci_controller hose;
};
@@ -482,6 +483,147 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie, struct
ls_pcie_info *info)
}
}
+#ifdef CONFIG_FSL_LSCH3
+/*
+ * Return next available LUT index.
+ */
+static int ls_pcie_next_lut_index(struct ls_pcie *pcie)
+{
+ if (pcie->next_lut_index < PCIE_LUT_ENTRY_COUNT)
+ return pcie->next_lut_index++;
+ else
+ return -1; /* LUT is full */
+}
+
+/*
+ * Program a single LUT entry
+ */
+static void ls_pcie_lut_set_mapping(struct ls_pcie *pcie, int index, u32 devid,
+u32 streamid)
+{
+ void __iomem *lut;
+
+ lut = pcie->dbi + PCIE_LUT_BASE;
+
+ /* leave mask as all zeroes, want to match all bits */
+ writel((devid << 16), lut + PCIE_LUT_UDR(index));
+ writel(streamid | PCIE_LUT_ENABLE, lut + PCIE_LUT_LDR(index));
+}
+
+/* returns the next available streamid */
+static u32 ls_pcie_next_streamid(void)
+{
+ static int next_stream_id = FSL_PEX_STREAM_ID_START;
+
+ if (next_stream_id > FSL_PEX_STREAM_ID_END)
+ return 0x;
+
+ return next_stream_id++;
+}
+
+/*
+ * An msi-map is a property to be added to the pci controller
+ * node. It is a table, where each entry consists of 4 fields
+ * e.g.:
+ *
+ * msi-map = <[devid] [phandle-to-msi-ctrl] [stream-id] [count]
+ * [devid] [phandle-to-msi-ctrl] [stream-id] [count]>;
+ */
+static void fdt_pcie_set_msi_map_entry(void *blob, struct ls_pcie *pcie,
+ u32 devid, u32 streamid)
+{
+ char pcie_path[19];
+ u32 *prop;
+ u32 phandle;
+ int nodeoffset;
+
+ /* find pci controller node */
+ snprintf(pcie_path, sizeof(pcie_path), "/soc/pcie@%llx",
+(u64)pcie->dbi);
+ nodeoffset = fdt_path_offset(blob, pcie_path);
+ if (nodeoffset < 0) {
+ printf("\n%s: ERROR: unable to update PCIe node: %s\n",
+ __func__, pcie_path);
+ return;
+ }
+
+ /* get phandle to MSI controller */
+ prop = (u32 *)fdt_getprop(blob, nodeoffset, "msi-parent", 0);
+ if (prop == NULL) {
+ printf("\n%s: ERROR: missing msi-parent: %s\n", __func__,
+ pcie_path);
+ return;
+ }
+ phandle = be32_to_cpu(*prop);
+
+ /* set one msi-map row */
+ fdt_appendprop_u32(blob, nodeoffset, "msi-map", devid);
+ fdt_appendprop_u32(blob, nodeoffset, "msi-map", phandle);
+ fdt_appendprop_u32(blob, nodeoffset, "msi-map", streamid);
+ fdt_appendprop_u32(blob, nodeoffset, "msi-map", 1);
+}
+
+static void fdt_fixup_pcie(void *blob)
+{
+ unsigned int found_multi = 0;
+ unsigned char header_type;
+ int index;
+ u32 streamid;
+ pci_dev_t dev;
+ int bus;
+ unsigned short id;
+ struct pci_controller *hose;
+ struct ls_pcie *pcie;
+ int i;
+
+ for (i = 0, hose = pci_get_hose_head(); hose; hose = hose->next, i++) {
+ pcie = hose->priv_data;
+ for (bus = hose->first_busno; bus <= hose->last_busno; bus++) {
+
+ for (dev = PCI_BDF(bus, 0, 0);
+dev < PCI_BDF(bus, PCI_MAX_PCI_DEVICES - 1,
+ PCI_MAX_PCI_FUNCTIONS - 1);
+dev += PCI_BDF(0, 0, 1)) {
+
+ if (PCI_FUNC(dev) && !found_multi)
+ continue;
+
+ pci_read_config_word(dev, PCI_VENDOR_ID, &id);
+
+ pci_read_config_byte(dev, PCI_HEADER_TYPE,
+&header_type);
+
+ if ((id == 0x) || (id == 0x))
+
[U-Boot] [PATCH 4/5 v6] pci/layerscape: add defines for LUT
From: Stuart Yoder The per-PCI controller LUT (Look-Up-Table) is a 32-entry table that maps PCI requester IDs (bus/dev/fun) to a stream ID. Add defines for the register offsets. Signed-off-by: Stuart Yoder --- -v6: first version of this patch, just add the LUT #defines .../include/asm/arch-fsl-layerscape/immap_lsch3.h |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h index 91f3ce8..d04e336 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h @@ -86,6 +86,10 @@ #define PCIE_LUT_BASE 0x8 #define PCIE_LUT_LCTRL00x7F8 #define PCIE_LUT_DBG 0x7FC +#define PCIE_LUT_UDR(n) (0x800 + (n) * 8) +#define PCIE_LUT_LDR(n) (0x804 + (n) * 8) +#define PCIE_LUT_ENABLE (1 << 31) +#define PCIE_LUT_ENTRY_COUNT32 /* Device Configuration */ #define DCFG_BASE 0x01e0 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Ethernet not found on Arria 5.
Hi, > Why are you constantly hung on this FPGA part ? The ethernet is not > routed through the FPGA, it is connected directly to the HPS. Thus, > you don't have to care about the FPGA at all, you only care about the > configuration of the HPS. Please excuse me for my small experience in this topic. I'm just trying to find the way how to solve this issue. Maybe then take HPS dumps and compare them? What I have for now: OK case (U-Boot 2013): ARP packets are sent from board to PC and back. ICMP packets are sent from board to PC and back. Ping is successful. NOK case(U-Boot 2016): ARP packets are sent from board to PC. PC sends ARP reply but it is not recognized by the board. Ping fails. However when the board is "waiting" for ARP reply from the PC it can process ICMP packets from the PC and send reply to them. I started thinking about: "What is that special in those ARP packets?" Best regards, Denis Bakhvalov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location
Hi Jagan, > -Original Message- > From: jt...@openedev.com [mailto:jt...@openedev.com] > Sent: Wednesday, March 09, 2016 9:02 PM > To: Vikas MANOCHA > Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko Schocher; > Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon Glass; Stefan > Roese; Thomas Chou; Vadzim Dambrouski > Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver > location > > On 2016-03-09 23:18, Vikas MANOCHA wrote: > > Hi Jagan , > > > >> On Mar 9, 2016, at 6:53 PM, Jagan Teki wrote: > >> > >>> On Thursday 10 March 2016 04:48 AM, Vikas Manocha wrote: > >>> Same flash driver can be used by other stm32 families like stm32f7. > >>> Better place for this driver would be mtd driver location. > >> > >> What kind of flash is it, parallel or serial NOR? > > > > It is embedded 256 bit NOR flash. > > OK, I thought it's similar to SST25L. > > Can't we detect this through cfi_flash framework? No, it is not possible. Cheers, Vikas > > -- > Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm: use common instructions applicable to armv7m & other arm archs
Just a reminder to apply this patch. Cheers, Vikas > -Original Message- > From: Vikas MANOCHA > Sent: Friday, February 05, 2016 10:43 AM > To: albert.u.b...@aribaud.net; h...@denx.de > Cc: Vikas MANOCHA; Simon Glass; Stefan Roese; Przemyslaw Marczak; > re...@wp.pl; open list > Subject: [PATCH v3] arm: use common instructions applicable to armv7m & > other arm archs > > This patch cleans the code by using instructions allowed for armv7m as well > as other Arm archs. > > Signed-off-by: Vikas Manocha > Reviewed-by: Simon Glass > Reviewed-by: Heiko Schocher > --- > Changes in v3: moved the comment to right location. > Changes in v2: reword message commit. Removed info regarding BIC > instruction on SP, was creating confusion. > > arch/arm/lib/crt0.S | 25 +++-- > 1 file changed, 7 insertions(+), 18 deletions(-) > > diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index 2f4c14e..d9078aa > 100644 > --- a/arch/arm/lib/crt0.S > +++ b/arch/arm/lib/crt0.S > @@ -71,18 +71,12 @@ ENTRY(_main) > */ > > #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) > - ldr sp, =(CONFIG_SPL_STACK) > + ldr r0, =(CONFIG_SPL_STACK) > #else > - ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) > + ldr r0, =(CONFIG_SYS_INIT_SP_ADDR) > #endif > -#if defined(CONFIG_CPU_V7M) /* v7M forbids using SP as BIC > destination */ > - mov r3, sp > - bic r3, r3, #7 > - mov sp, r3 > -#else > - bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ > -#endif > - mov r0, sp > + bic r0, r0, #7 /* 8-byte alignment for ABI compliance */ > + mov sp, r0 > bl board_init_f_alloc_reserve > mov sp, r0 > /* set up gd here, outside any C code */ @@ -100,14 +94,9 @@ > ENTRY(_main) > * 'here' but relocated. > */ > > - ldr sp, [r9, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */ > -#if defined(CONFIG_CPU_V7M) /* v7M forbids using SP as BIC > destination */ > - mov r3, sp > - bic r3, r3, #7 > - mov sp, r3 > -#else > - bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ > -#endif > + ldr r0, [r9, #GD_START_ADDR_SP] /* sp = gd->start_addr_sp */ > + bic r0, r0, #7 /* 8-byte alignment for ABI compliance */ > + mov sp, r0 > ldr r9, [r9, #GD_BD]/* r9 = gd->bd */ > sub r9, r9, #GD_SIZE/* new GD is below bd */ > > -- > 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location
On Thursday 10 March 2016 11:11 PM, Vikas MANOCHA wrote: Hi Jagan, -Original Message- From: jt...@openedev.com [mailto:jt...@openedev.com] Sent: Wednesday, March 09, 2016 9:02 PM To: Vikas MANOCHA Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko Schocher; Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon Glass; Stefan Roese; Thomas Chou; Vadzim Dambrouski Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location On 2016-03-09 23:18, Vikas MANOCHA wrote: Hi Jagan , On Mar 9, 2016, at 6:53 PM, Jagan Teki wrote: On Thursday 10 March 2016 04:48 AM, Vikas Manocha wrote: Same flash driver can be used by other stm32 families like stm32f7. Better place for this driver would be mtd driver location. What kind of flash is it, parallel or serial NOR? It is embedded 256 bit NOR flash. OK, I thought it's similar to SST25L. Can't we detect this through cfi_flash framework? No, it is not possible. Sorry, please add some details why it couldn't? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location
Hi, > -Original Message- > From: Jagan Teki [mailto:jt...@openedev.com] > Sent: Thursday, March 10, 2016 9:46 AM > To: Vikas MANOCHA > Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko Schocher; > Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon Glass; Stefan > Roese; Thomas Chou; Vadzim Dambrouski > Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver > location > > On Thursday 10 March 2016 11:11 PM, Vikas MANOCHA wrote: > > Hi Jagan, > > > >> -Original Message- > >> From: jt...@openedev.com [mailto:jt...@openedev.com] > >> Sent: Wednesday, March 09, 2016 9:02 PM > >> To: Vikas MANOCHA > >> Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko > >> Schocher; Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon > >> Glass; Stefan Roese; Thomas Chou; Vadzim Dambrouski > >> Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd > >> driver location > >> > >> On 2016-03-09 23:18, Vikas MANOCHA wrote: > >>> Hi Jagan , > >>> > On Mar 9, 2016, at 6:53 PM, Jagan Teki wrote: > > > On Thursday 10 March 2016 04:48 AM, Vikas Manocha wrote: > > Same flash driver can be used by other stm32 families like stm32f7. > > Better place for this driver would be mtd driver location. > > What kind of flash is it, parallel or serial NOR? > >>> > >>> It is embedded 256 bit NOR flash. > >> > >> OK, I thought it's similar to SST25L. > >> > >> Can't we detect this through cfi_flash framework? > > > > No, it is not possible. > > Sorry, please add some details why it couldn't? The embedded flash in stm32 is not cfi flash. Cfi tables to find the flash characteristics are not implemented. Cheers, Vikas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location
On Thursday 10 March 2016 11:22 PM, Vikas MANOCHA wrote: Hi, -Original Message- From: Jagan Teki [mailto:jt...@openedev.com] Sent: Thursday, March 10, 2016 9:46 AM To: Vikas MANOCHA Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko Schocher; Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon Glass; Stefan Roese; Thomas Chou; Vadzim Dambrouski Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location On Thursday 10 March 2016 11:11 PM, Vikas MANOCHA wrote: Hi Jagan, -Original Message- From: jt...@openedev.com [mailto:jt...@openedev.com] Sent: Wednesday, March 09, 2016 9:02 PM To: Vikas MANOCHA Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko Schocher; Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon Glass; Stefan Roese; Thomas Chou; Vadzim Dambrouski Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location On 2016-03-09 23:18, Vikas MANOCHA wrote: Hi Jagan , On Mar 9, 2016, at 6:53 PM, Jagan Teki wrote: On Thursday 10 March 2016 04:48 AM, Vikas Manocha wrote: Same flash driver can be used by other stm32 families like stm32f7. Better place for this driver would be mtd driver location. What kind of flash is it, parallel or serial NOR? It is embedded 256 bit NOR flash. OK, I thought it's similar to SST25L. Can't we detect this through cfi_flash framework? No, it is not possible. Sorry, please add some details why it couldn't? The embedded flash in stm32 is not cfi flash. Cfi tables to find the flash characteristics are not implemented. OK, all your saying that this not quite exactly a cfi, different kind wrt sst32. true? then please convert this into MTD driver model format. If needed take an example of existing MTD uclass driver. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location
Hi Jagan, > -Original Message- > From: Jagan Teki [mailto:jt...@openedev.com] > Sent: Thursday, March 10, 2016 9:58 AM > To: Vikas MANOCHA > Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko Schocher; > Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon Glass; Stefan > Roese; Thomas Chou; Vadzim Dambrouski > Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver > location > > On Thursday 10 March 2016 11:22 PM, Vikas MANOCHA wrote: > > Hi, > > > >> -Original Message- > >> From: Jagan Teki [mailto:jt...@openedev.com] > >> Sent: Thursday, March 10, 2016 9:46 AM > >> To: Vikas MANOCHA > >> Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko > >> Schocher; Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon > >> Glass; Stefan Roese; Thomas Chou; Vadzim Dambrouski > >> Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd > >> driver location > >> > >> On Thursday 10 March 2016 11:11 PM, Vikas MANOCHA wrote: > >>> Hi Jagan, > >>> > -Original Message- > From: jt...@openedev.com [mailto:jt...@openedev.com] > Sent: Wednesday, March 09, 2016 9:02 PM > To: Vikas MANOCHA > Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko > Schocher; Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon > Glass; Stefan Roese; Thomas Chou; Vadzim Dambrouski > Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd > driver location > > On 2016-03-09 23:18, Vikas MANOCHA wrote: > > Hi Jagan , > > > >> On Mar 9, 2016, at 6:53 PM, Jagan Teki > wrote: > >> > >>> On Thursday 10 March 2016 04:48 AM, Vikas Manocha wrote: > >>> Same flash driver can be used by other stm32 families like stm32f7. > >>> Better place for this driver would be mtd driver location. > >> > >> What kind of flash is it, parallel or serial NOR? > > > > It is embedded 256 bit NOR flash. > > OK, I thought it's similar to SST25L. > > Can't we detect this through cfi_flash framework? > >>> > >>> No, it is not possible. > >> > >> Sorry, please add some details why it couldn't? > > > > The embedded flash in stm32 is not cfi flash. Cfi tables to find the flash > characteristics are not implemented. > > OK, all your saying that this not quite exactly a cfi, different kind wrt > sst32. > true? Yes, flash is embedded in the stm32 micro & details like data width etc are not relevant for the user. Sst32 ? , sorry but I am not aware of it and sst32L. >then please convert this into MTD driver model format. > > If needed take an example of existing MTD uclass driver. Can you please point me to it ? Cheers, Vikas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location
On Thursday 10 March 2016 11:47 PM, Vikas MANOCHA wrote: Hi Jagan, -Original Message- From: Jagan Teki [mailto:jt...@openedev.com] Sent: Thursday, March 10, 2016 9:58 AM To: Vikas MANOCHA Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko Schocher; Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon Glass; Stefan Roese; Thomas Chou; Vadzim Dambrouski Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location On Thursday 10 March 2016 11:22 PM, Vikas MANOCHA wrote: Hi, -Original Message- From: Jagan Teki [mailto:jt...@openedev.com] Sent: Thursday, March 10, 2016 9:46 AM To: Vikas MANOCHA Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko Schocher; Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon Glass; Stefan Roese; Thomas Chou; Vadzim Dambrouski Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location On Thursday 10 March 2016 11:11 PM, Vikas MANOCHA wrote: Hi Jagan, -Original Message- From: jt...@openedev.com [mailto:jt...@openedev.com] Sent: Wednesday, March 09, 2016 9:02 PM To: Vikas MANOCHA Cc: u-boot@lists.denx.de; Albert Aribaud; Antonio Borneo; Heiko Schocher; Kamil Lulko; Matt Porter; re...@wp.pl; Scott Wood; Simon Glass; Stefan Roese; Thomas Chou; Vadzim Dambrouski Subject: Re: [RESEND 1/2] stm32: stm32f4: move flash driver to mtd driver location On 2016-03-09 23:18, Vikas MANOCHA wrote: Hi Jagan , On Mar 9, 2016, at 6:53 PM, Jagan Teki wrote: On Thursday 10 March 2016 04:48 AM, Vikas Manocha wrote: Same flash driver can be used by other stm32 families like stm32f7. Better place for this driver would be mtd driver location. What kind of flash is it, parallel or serial NOR? It is embedded 256 bit NOR flash. OK, I thought it's similar to SST25L. Can't we detect this through cfi_flash framework? No, it is not possible. Sorry, please add some details why it couldn't? The embedded flash in stm32 is not cfi flash. Cfi tables to find the flash characteristics are not implemented. OK, all your saying that this not quite exactly a cfi, different kind wrt sst32. true? Yes, flash is embedded in the stm32 micro & details like data width etc are not relevant for the user. Sst32 ? , sorry but I am not aware of it and sst32L. then please convert this into MTD driver model format. If needed take an example of existing MTD uclass driver. Can you please point me to it ? The board your using with this driver has fdt and dm support? If so, it is quite straight forward, take an example of this drivers/mtd/altera_qspi.c - register with MTD_UCLASS - add your erase/write and read ops through mtd_ops ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] usb: legacy_hub_port_reset(): Speedup hub reset handling
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
Start with a short USB hub reset delay of 10ms. This can be enough for
some configurations.
The 2nd delay at the of the loop is completely removed. Since the delay
hasn't been long enough, a longer delay time of 200ms is assigned. And
will be used in the next loop round.
This hub reset handling is also used in the v4.4 Linux USB driver,
hub_port_reset().
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Hans de Goede
Cc: Stephen Warren
Cc: Marek Vasut
Since this is good enough for the kernel it should be good enough for us:
Acked-by: Hans de Goede
Regards,
Hans
---
common/usb_hub.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index e1de813..10fdd3c 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -46,6 +46,9 @@ DECLARE_GLOBAL_DATA_PTR;
#define USB_BUFSIZ512
+#define HUB_SHORT_RESET_TIME 10
+#define HUB_LONG_RESET_TIME200
+
/* TODO(s...@chromium.org): Remove this when CONFIG_DM_USB is defined */
static struct usb_hub_device hub_dev[USB_MAX_HUB];
static int usb_hub_index;
@@ -164,6 +167,7 @@ int legacy_hub_port_reset(struct usb_device *dev, int port,
int err, tries;
ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);
unsigned short portstatus, portchange;
+ int delay = HUB_SHORT_RESET_TIME; /* start with short reset delay */
#ifdef CONFIG_DM_USB
debug("%s: resetting '%s' port %d...\n", __func__, dev->dev->name,
@@ -176,7 +180,7 @@ int legacy_hub_port_reset(struct usb_device *dev, int port,
if (err < 0)
return err;
- mdelay(200);
+ mdelay(delay);
if (usb_get_port_status(dev, port + 1, portsts) < 0) {
debug("get_port_status failed status %lX\n",
@@ -215,7 +219,8 @@ int legacy_hub_port_reset(struct usb_device *dev, int port,
if (portstatus & USB_PORT_STAT_ENABLE)
break;
- mdelay(200);
+ /* Switch to long reset delay for the next round */
+ delay = HUB_LONG_RESET_TIME;
}
if (tries == MAX_TRIES) {
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] defconfig: ls1021aqds_sdcard_qspi: Enable SPI-NOR
On 9 March 2016 at 22:29, york sun wrote: > On 03/08/2016 07:04 PM, Alison Wang wrote: >> As QSPI driver is supported in ls1021aqds_sdcard_qspi_defconfig, SPI-NOR >> with MTD uclass, CONFIG_MTD_DATAFLASH and new flash vendor config >> CONFIG_SPI_NOR_SPANSION need be enabled. >> >> Signed-off-by: Alison Wang >> --- >> configs/ls1021aqds_sdcard_qspi_defconfig | 7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/configs/ls1021aqds_sdcard_qspi_defconfig >> b/configs/ls1021aqds_sdcard_qspi_defconfig >> index cd75af6..25ab3ee 100644 >> --- a/configs/ls1021aqds_sdcard_qspi_defconfig >> +++ b/configs/ls1021aqds_sdcard_qspi_defconfig >> @@ -7,8 +7,11 @@ CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-duart" >> # CONFIG_CMD_SETEXPR is not set >> CONFIG_OF_CONTROL=y >> CONFIG_DM=y >> -CONFIG_SPI_FLASH=y >> -CONFIG_SPI_FLASH_SPANSION=y >> +CONFIG_MTD=y >> +CONFIG_MTD_SPI_NOR=y >> +CONFIG_MTD_M25P80=y >> +CONFIG_MTD_DATAFLASH=y >> +CONFIG_SPI_NOR_SPANSION=y >> CONFIG_NETDEVICES=y >> CONFIG_E1000=y >> CONFIG_SYS_NS16550=y >> > > Put a note for myself, this patch is on top of spi-nor patchset Jagan is > working on. -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] defconfig: ls1021aqds_sdcard_qspi: Enable SPI-NOR
On 11 March 2016 at 00:23, Jagan Teki wrote: > On 9 March 2016 at 22:29, york sun wrote: >> On 03/08/2016 07:04 PM, Alison Wang wrote: >>> As QSPI driver is supported in ls1021aqds_sdcard_qspi_defconfig, SPI-NOR >>> with MTD uclass, CONFIG_MTD_DATAFLASH and new flash vendor config >>> CONFIG_SPI_NOR_SPANSION need be enabled. >>> >>> Signed-off-by: Alison Wang >>> --- >>> configs/ls1021aqds_sdcard_qspi_defconfig | 7 +-- >>> 1 file changed, 5 insertions(+), 2 deletions(-) >>> >>> diff --git a/configs/ls1021aqds_sdcard_qspi_defconfig >>> b/configs/ls1021aqds_sdcard_qspi_defconfig >>> index cd75af6..25ab3ee 100644 >>> --- a/configs/ls1021aqds_sdcard_qspi_defconfig >>> +++ b/configs/ls1021aqds_sdcard_qspi_defconfig >>> @@ -7,8 +7,11 @@ CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-duart" >>> # CONFIG_CMD_SETEXPR is not set >>> CONFIG_OF_CONTROL=y >>> CONFIG_DM=y >>> -CONFIG_SPI_FLASH=y >>> -CONFIG_SPI_FLASH_SPANSION=y >>> +CONFIG_MTD=y >>> +CONFIG_MTD_SPI_NOR=y >>> +CONFIG_MTD_M25P80=y >>> +CONFIG_MTD_DATAFLASH=y >>> +CONFIG_SPI_NOR_SPANSION=y >>> CONFIG_NETDEVICES=y >>> CONFIG_E1000=y >>> CONFIG_SYS_NS16550=y >>> >> >> Put a note for myself, this patch is on top of spi-nor patchset Jagan is >> working on. Will add these on to my spi-nor series and send for final review and test early on next week. - same as Qianyu Gong changes. thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] usb: Remove 200 ms delay in usb_hub_port_connect_change()
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
This patch removes 2 mdelay(200) calls from usb_hub_port_connect_change().
These delays don't seem to be necessary. At least not in my tests. Here
the number for a custom x86 Bay Trail board (not in mainline yet) with
a quite large and complex USB hub infrastructure.
Without this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 28.415 seconds
With this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 24.811 seconds
So ~3.5 seconds of USB scanning time reduction.
These mdelay calls are removed if CONFIG_USB_FAST_SCAN is defined. They
are not removed per default yet. It would be good to test with this
option enabled on many other boards. And once we have a good testing
base we can decide to remove these delays completely, including this
macro.
There indeed is no reason at all to delay before the reset and the kernel
does not wait with checking the USB_PORT_STAT_SPEED_MASK once the
reset completes, so I see no reason why we should:
Acked-by: Hans de Goede
Regards,
Hans
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Hans de Goede
Cc: Stephen Warren
Cc: Marek Vasut
---
common/usb_hub.c | 4
1 file changed, 4 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 10fdd3c..660f4f4 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -275,7 +275,9 @@ int usb_hub_port_connect_change(struct usb_device *dev, int
port)
if (!(portstatus & USB_PORT_STAT_CONNECTION))
return -ENOTCONN;
}
+#if !defined(CONFIG_USB_FAST_SCAN)
mdelay(200);
+#endif
/* Reset the port */
ret = legacy_hub_port_reset(dev, port, &portstatus);
@@ -285,7 +287,9 @@ int usb_hub_port_connect_change(struct usb_device *dev, int
port)
return ret;
}
+#if !defined(CONFIG_USB_FAST_SCAN)
mdelay(200);
+#endif
switch (portstatus & USB_PORT_STAT_SPEED_MASK) {
case USB_PORT_STAT_SUPER_SPEED:
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] usb: Remove 1 second per port timeout in usb_hub_configure()
Hi, On 10-03-16 16:50, Stefan Roese wrote: On complex USB infrastructures, with many hubs and therefore many (perhaps unconnected) ports, current U-Boot has a very long USB scanning time. On my current custom x86 board, this time is over 20 seconds!!! One of the biggest problems here is a 1 second delay (timeout) in usb_hub_configure() to check, if a USB device is connected to a port. As this is done for each port, this timeout sums up over all unconnected ports. This patch removes this 1 seconds per port timeout from usb_hub_configure(). If you look at the commit which added the delay, you will see the need for this delay clearly documented. The USB spec gives devices up to one second to connect after they get power, and some devices actually use almost that entire second. Sure what you're doing will work most of the time, but works most of the time is not really helpful, and will just cause hard to debug problems. Instead what we need to do is implement parallel usb scanning, I've done some suggestions on how to do this here: http://lists.denx.de/pipermail/u-boot/2016-February/245243.html Regards, Hans All my USB devices are still detected correctly on my platform. And I'm using 4 different USB keys right now. Including a problematic "Intenso Alu Line" key. Here the numbers for my current board: Without this patch: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 24.811 seconds With this patch: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 10.822 seconds So ~14 seconds of USB scanning time reduction. Again, this timeout is only removed if CONFIG_USB_FAST_SCAN is defined. Once more tests are done on multiple other platforms we can decide to remove this timeout completely. Signed-off-by: Stefan Roese Cc: Simon Glass Cc: Hans de Goede Cc: Stephen Warren Cc: Marek Vasut --- common/usb_hub.c | 4 1 file changed, 4 insertions(+) diff --git a/common/usb_hub.c b/common/usb_hub.c index 660f4f4..780291f 100644 --- a/common/usb_hub.c +++ b/common/usb_hub.c @@ -478,7 +478,11 @@ static int usb_hub_configure(struct usb_device *dev) unsigned short portstatus, portchange; int ret; ulong start = get_timer(0); +#if defined(CONFIG_USB_FAST_SCAN) + uint delay = 0; +#else uint delay = CONFIG_SYS_HZ; +#endif #ifdef CONFIG_SANDBOX if (state_get_skip_delays()) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] usb: usb_hub_power_on(): Use 100ms power-on delay instead of 1 sec (optionally)
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
In a system with a complex USB infrastrcture (many USB hubs), the
power-on delay of mininimum 1 second for each USB hub results in a quite
big USB scanning time. Many USB devices can deal with much lower
power-on delays. In my test system, even 10ms seems to be enough
for the USB device to get detected correctly. This patch now
reduces the minimum 1 second delay to a minumum of 100ms instead.
This results in a big USB scan time reduction:
Here the numbers for my current board:
Without this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 10.822 seconds
With this patch:
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 6.319 seconds
So ~4.5 seconds of USB scanning time reduction.
I'm not really sure if this patch can be accepted in general as is.
In patch 0d437bca [usb: hub: fix power good delay timing] by Stephen
Warren, this delay was changes according to "Connect Timing ECN.pdf"
to a total of 1 second plus the hub port's power good time. Now its
changes back to 100ms which is a violation of this spec. But still,
for most USB devices this 100ms is more than enough. So its a valid
use-case to lower this time in special (perhaps static) USB
environments.
Actually that 1 second + poweron delay is why we had the 1 sec
delay in usb_hub_configure(), that is where we wait for a device
to show up. Note that we can already save a lot of time, by
first powering up all ports and then doing the 1 sec wait
and then checking all ports without needing to delay any further.
Or even better:
1) turn on all ports
2) do power-on-delay (either 2ms * bPwrOn2PwrGood from descriptor, or
100ms which ever one is LARGER)
3) set a timeout val 1 sec from now, loop over all ports and quit
the loop when either all ports are connected (we already skip the
per port delay in this connected case now), or when the 1 sec
expires. There is no reason for the 1 sec per port delay,
one sec + bPwrOn2PwrGood delay is enough for all ports
###
Note that even better would be to in 3 first calls some sort of
probe_prepare function, which if the child is a hub itself, does
the poweron, and records the timeout for its loop and runs its
loop once (to probe_prepare its children if they come up immediately).
And then only once the loop over all ports ends, call the real
probe which will then do usb_hub_configure() for its (hub)
children using the timeout recorded during the probe_prepare,
and will thus likely be able to skip a large part of that
1 sec waiting since that was already waited in the parent
hub's usb_hub_configure() call.
Note this would speed up scanning deep trees of hubs, if
we have multiple usb controllers, it would also be really
good to probe them in parallel as described here:
http://lists.denx.de/pipermail/u-boot/2016-February/245243.html
(yes I'm repeating myself :)
Regards,
Hans
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Hans de Goede
Cc: Stephen Warren
Cc: Marek Vasut
---
common/usb_hub.c | 4
1 file changed, 4 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 780291f..d5fcd27 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -120,7 +120,11 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
pgood_delay = max(pgood_delay,
(unsigned)simple_strtol(env, NULL, 0));
debug("pgood_delay=%dms\n", pgood_delay);
+#if defined(CONFIG_USB_FAST_SCAN)
+ mdelay(pgood_delay + 100);
+#else
mdelay(pgood_delay + 1000);
+#endif
}
void usb_hub_reset(void)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] usb: Don't reset the USB hub a 2nd time
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
Debugging has shown, that all USB hubs are being resetted twice while
USB scanning. This introduces additional delays and makes USB scanning
even more slow. Testing has shown that this 2nd USB hub reset doesn't
seem to be necessary.
This patch now removes this 2nd USB hub reset if CONFIG_USB_FAST_SCAN
is defined. Resulting in faster USB scan time. Here the current
number:
Without this patch:
=> time usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 6.319 seconds
With this patch:
=> time usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 3.777 seconds
So ~2.5 seconds of USB scanning time reduction.
Again, this 2nd reset is only removed if CONFIG_USB_FAST_SCAN is
defined. Once more tests are done on multiple other platforms we
can decide to remove this 2nd reset completely.
I see no reason to make the removal conditional, I believe that
this is some relic workaround for likely long fixed bugs and
we should just remove it completely (for v2016.07).
Regards,
Hans
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Hans de Goede
Cc: Stephen Warren
Cc: Marek Vasut
---
common/usb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index c7b8b0e..b96a2f6 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -920,6 +920,11 @@ __weak int usb_alloc_device(struct usb_device *udev)
static int usb_hub_port_reset(struct usb_device *dev, struct usb_device *hub)
{
if (hub) {
+#if !defined(CONFIG_USB_FAST_SCAN)
+ /*
+* Is this 2nd hub port reset necessary? The port has already
+* been reset in usb_hub_port_connect_change() before.
+*/
unsigned short portstatus;
int err;
@@ -929,6 +934,7 @@ static int usb_hub_port_reset(struct usb_device *dev,
struct usb_device *hub)
printf("\n Couldn't reset port %i\n", dev->portnr);
return err;
}
+#endif
} else {
usb_reset_root_port(dev);
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] usb: Implement static USB port configuration to speed up USB scanning
Hi,
On 10-03-16 16:50, Stefan Roese wrote:
This patch implements an optionally quasi static USB port configuration.
This is done by using an environment variable, that describes the ports
that shall be scanned at the next USB scans (usb start, usb reset).
The "usb_port_use" env variable is used to describe this static USB
configuration. For this, each USB hub is represented by a 8-bit value.
Making it possible to configure a maximum of 8 ports for each USB hub.
A 64-bit representation is used, therefore 8 USB hubs can be described
in total.
Here an example for this "usb_port_use" environment variable:
usb_port_use = 00040301
---
1st USB hub: 0x01 -> Use port 1 (first port)
2nd USB hub: 0x03 -> Use port 1 and 2
3rd USB hub: 0x04 -> Use port 3
4th USB hub: 0x00 -> Use no ports
...
8th USB hub: 0x00 -> Use no ports
To make this procedure of configuring this env variable less error prone
and less painful, this patch also introduces another env variable that
is dynamically generated at each USB scan: "usb_port_detected". This
variable is similar to "usb_port_use". It has a bit enabled for each
port that has been detected. This can be easily used on a new system,
where the USB configuration is static in this way:
Run the USB scan (usb start, usb reset) without the "usb_port_use"
variable set. This will result in all ports being scanned and the result
written into the "usb_port_detected" variable. To configure the USB
subsystem to only scan these specific USB ports upon the next
scans, you only need to write the value from "usb_port_detected"
into the "usb_port_use" variable:
=> setenv usb_port_use ${usb_port_detected}
=> saveenv
The next scans will only scan those enabled ports.
Its of course also possible to manually "tune" this env variable. If
some ports are not needed in U-Boot, they can be disabled this way.
This will result in less USB hub ports getting scanned and therefore
in a faster USB scan time. Here an example:
With all USB devices enabled (usb_port_use not set):
This will fall apart when you get multiple root hubs,
if you want to do this (I believe there is much more low hanging fruit
see my previous mails), you somehow need to describe the entire
path to the hub in the env variable, currently if one hub gets removed,
other hubs which are children of the same parent will get a different
number in your hub-numbering scheme and things go awry, also what about hubs
on a second host controller, do those number on from the hub-numbering of
the first hcd ? That seems vary fragile and will break when we add
(semi) parallel scanning.
So NACK because this disallows later implementing parallel scanning
without regressing this feature.
Regards,
Hans
=> setenv usb_port_use
=> time usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 9 USB Device(s) found
time: 3.776 seconds
=> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 0mA)
|
+-8 Mass Storage (480 Mb/s, 200mA)
|6989 Intenso Alu Line EE706F5E
|
+-9 Mass Storage (480 Mb/s, 200mA)
|JetFlash Mass Storage Device 3281440601
|
+-3 Hub (480 Mb/s, 100mA)
| |
| +-4 Hub (12 Mb/s, 100mA)
|
+-5 Hub (480 Mb/s, 0mA)
|
+-6 Mass Storage (480 Mb/s, 200mA)
|Kingston DataTraveler 2.0 50E549C688C4BE7189942766
|
+-7 Mass Storage (480 Mb/s, 98mA)
USBest Technology USB Mass Storage Device 09092207fbf0c4
=> printenv usb_port_detected
usb_port_detected=000501080f01
With only some USB devices enabled:
=> setenv usb_port_use 0c01
=> time usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
time: 1.354 seconds
=> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 0mA)
|
+-3 Mass Storage (480 Mb/s, 200mA)
|6989 Intenso Alu Line EE706F5E
|
+-4 Mass Storage (480 Mb/s, 200mA)
JetFlash Mass Storage Device 3281440601
So this feature of USB port enabling via environment variable is very
helpful to further reduce the USB scanning time in some configurations.
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Hans de Goede
Cc: Stephen Warren
Cc: Marek Vasut
---
common/usb_hub.c | 44
1 file changed, 44 insertions(+)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index d5fcd27..b600cfa 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -353,6 +353,10 @@ static int usb_hub_configure(struct usb_device *dev)
struct usb_hub_descriptor *descriptor;
struct usb_hub_device *hub;
__maybe_unused struct usb_hub_status *hubsts;
+ static u64 port_active;
+ u32 port_use = 0xff;/* Default: use all ports */
+ const char *env;
+ char str[18];
in
[U-Boot] [PATCH] sunxi: Add defconfig and dts for Difrence DIT4350 tablet
The Difrnce dit4350 tablet is a tiny tablet with a 4.3" 16:9 480x272 LCD,
A13 SoC, 512M RAM, 4G NAND, solomon systech ssd2532qn6 touchscreen at
i2c1 address 0x48, Memsic MXC622X accelerometer at i2c1 address 0x15 and
rtl8188etv wifi.
The dts file is identical to the one submitted to the upstream kernel.
Signed-off-by: Hans de Goede
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/sun5i-a13-difrnce-dit4350.dts | 226 +
board/sunxi/MAINTAINERS| 1 +
configs/difrnce_dit4350_defconfig | 23 +++
4 files changed, 251 insertions(+)
create mode 100644 arch/arm/dts/sun5i-a13-difrnce-dit4350.dts
create mode 100644 configs/difrnce_dit4350_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a8bc7b0..9566c81 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -135,6 +135,7 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-r7-tv-dongle.dtb \
sun5i-a10s-wobo-i5.dtb \
sun5i-a13-ampe-a76.dtb \
+ sun5i-a13-difrnce-dit4350.dtb \
sun5i-a13-empire-electronix-d709.dtb \
sun5i-a13-hsg-h702.dtb \
sun5i-a13-inet-86vs.dtb \
diff --git a/arch/arm/dts/sun5i-a13-difrnce-dit4350.dts
b/arch/arm/dts/sun5i-a13-difrnce-dit4350.dts
new file mode 100644
index 000..6546fa0
--- /dev/null
+++ b/arch/arm/dts/sun5i-a13-difrnce-dit4350.dts
@@ -0,0 +1,226 @@
+/*
+ * Copyright 2016 Hans de Goede
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun5i-a13.dtsi"
+#include "sunxi-common-regulators.dtsi"
+#include
+#include
+#include
+#include
+#include
+
+/ {
+ model = "Difrnce DIT4350";
+ compatible = "difrnce,dit4350", "allwinner,sun5i-a13";
+
+ aliases {
+ serial0 = &uart1;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+ default-brightness-level = <8>;
+ /* TODO: backlight uses axp gpio1 as enable pin */
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+
+ axp209: pmic@34 {
+ reg = <0x34>;
+ interrupts = <0>;
+ };
+};
+
+#include "axp209.dtsi"
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+
+ pcf8563: rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&lradc {
+ vref-supply = <®_ldo2>;
+ status = "okay";
+
+ button@200 {
+ label = "Volume Up";
+ linux,code = ;
+ channel = <0>;
+ voltage = <20>;
+ };
+
+ button@400 {
+ label = "Volume Dow
[U-Boot] [PATCH 1/4] arm: iproc: add NAND driver
From: Jiandong Zheng
Add support for the iproc NAND, and enable on Cygnus and NSP boards.
Signed-off-by: Jiandong Zheng
Signed-off-by: Steve Rae
---
There was a previous attempt to implement this "iproc NAND"
(see: http://patchwork.ozlabs.org/patch/505399), however, due to the
amount of changes required, it seemed better to implement the code
in a series of steps. This is the first step, where the "iproc_nand.c"
is essentially an empty file (with one function required to allow this
commit to build successfully).
arch/arm/include/asm/arch-bcmcygnus/configs.h | 11 +++
arch/arm/include/asm/arch-bcmnsp/configs.h| 11 +++
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/iproc_nand.c | 11 +++
drivers/mtd/nand/iproc_nand_cygnus.h | 111 +
drivers/mtd/nand/iproc_nand_ns_plus.h | 113 ++
6 files changed, 258 insertions(+)
create mode 100644 drivers/mtd/nand/iproc_nand.c
create mode 100644 drivers/mtd/nand/iproc_nand_cygnus.h
create mode 100644 drivers/mtd/nand/iproc_nand_ns_plus.h
diff --git a/arch/arm/include/asm/arch-bcmcygnus/configs.h
b/arch/arm/include/asm/arch-bcmcygnus/configs.h
index 3c07160..3bf7395 100644
--- a/arch/arm/include/asm/arch-bcmcygnus/configs.h
+++ b/arch/arm/include/asm/arch-bcmcygnus/configs.h
@@ -10,6 +10,7 @@
#include
/* uArchitecture specifics */
+#include <../../../drivers/mtd/nand/iproc_nand_cygnus.h>
/* Serial Info */
/* Post pad 3 bytes after each reg addr */
@@ -33,4 +34,14 @@
#define CONFIG_CMD_PING
#define CONFIG_CMD_MII
+/* NAND configuration */
+#define CONFIG_CMD_NAND
+#define CONFIG_NAND_IPROC
+#define CONFIG_SYS_NAND_IPROC_TIMING_MODE 5
+#define CONFIG_SYS_NAND_BASE 0
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+#define CONFIG_SYS_MAX_NAND_CHIPS 1
+#define CONFIG_SYS_NAND_SELF_INIT
+#define CONFIG_SYS_NAND_ONFI_DETECTION
+
#endif /* __ARCH_CONFIGS_H */
diff --git a/arch/arm/include/asm/arch-bcmnsp/configs.h
b/arch/arm/include/asm/arch-bcmnsp/configs.h
index 786deae..aeaea6a 100644
--- a/arch/arm/include/asm/arch-bcmnsp/configs.h
+++ b/arch/arm/include/asm/arch-bcmnsp/configs.h
@@ -10,6 +10,7 @@
#include
/* uArchitecture specifics */
+#include <../../../drivers/mtd/nand/iproc_nand_ns_plus.h>
/* Serial Info */
/* no padding */
@@ -19,4 +20,14 @@
#define CONFIG_CONS_INDEX 1
#define CONFIG_SYS_NS16550_COM10x18000300
+/* NAND configuration */
+#define CONFIG_CMD_NAND
+#define CONFIG_NAND_IPROC
+#define CONFIG_SYS_NAND_IPROC_TIMING_MODE 5
+#define CONFIG_SYS_NAND_BASE 0
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+#define CONFIG_SYS_MAX_NAND_CHIPS 1
+#define CONFIG_SYS_NAND_SELF_INIT
+#define CONFIG_SYS_NAND_ONFI_DETECTION
+
#endif /* __ARCH_CONFIGS_H */
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 6fb3718..bb3adbc 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o
obj-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_nand.o
obj-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o
obj-$(CONFIG_NAND_FSMC) += fsmc_nand.o
+obj-$(CONFIG_NAND_IPROC) += iproc_nand.o
obj-$(CONFIG_NAND_JZ4740) += jz4740_nand.o
obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o
obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o
diff --git a/drivers/mtd/nand/iproc_nand.c b/drivers/mtd/nand/iproc_nand.c
new file mode 100644
index 000..74f885a
--- /dev/null
+++ b/drivers/mtd/nand/iproc_nand.c
@@ -0,0 +1,11 @@
+/*
+ * Copyright 2015 Broadcom Corporation.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+
+void board_nand_init(void)
+{
+}
diff --git a/drivers/mtd/nand/iproc_nand_cygnus.h
b/drivers/mtd/nand/iproc_nand_cygnus.h
new file mode 100644
index 000..26a00a9
--- /dev/null
+++ b/drivers/mtd/nand/iproc_nand_cygnus.h
@@ -0,0 +1,111 @@
+/*
+ * Copyright 2015 Broadcom Corporation.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _IPROC_NAND_CYGNUS_H_
+#define _IPROC_NAND_CYGNUS_H_
+
+/*
+ * SoC specific definitions (Cygnus)
+ */
+
+#define REG_NAND_BASE 0x18046000
+#define REG_NAND_IDM_BASE 0xf8105000
+
+#define NAND_STRAP_TYPE_MASK 0x000f
+#define NAND_STRAP_TYPE_SHIFT 16
+#define NAND_STRAP_PAGE_MASK 0x0030
+#define NAND_STRAP_PAGE_SHIFT 20
+#define NAND_STRAP_WIDTH_MASK 0x0100
+#define NAND_STRAP_WIDTH_SHIFT 24
+
+#define NAND_STRAP_TYPE_DATA \
+/* sector_1k, ecclevel, spare_size */ \
+{ \
+ { 0, 0, 16 }, \
+ { 0, 1, 16 }, \
+ { 0, 4, 16 }, \
+ { 0, 8, 16 }, \
+ { 0, 8, 27 },
[U-Boot] [PATCH 4/4] arm: bcm: configure NAND device and environment
Configure the NAND device, define partition sizes, and create the environment space for Cygnus and NSP boards. Signed-off-by: Steve Rae --- arch/arm/include/asm/arch-bcmcygnus/configs.h | 33 +++ arch/arm/include/asm/arch-bcmnsp/configs.h| 33 +++ include/configs/bcm_ep_board.h| 3 --- 3 files changed, 66 insertions(+), 3 deletions(-) diff --git a/arch/arm/include/asm/arch-bcmcygnus/configs.h b/arch/arm/include/asm/arch-bcmcygnus/configs.h index 40a9f0e..ad94e31 100644 --- a/arch/arm/include/asm/arch-bcmcygnus/configs.h +++ b/arch/arm/include/asm/arch-bcmcygnus/configs.h @@ -44,6 +44,39 @@ #define CONFIG_SYS_NAND_SELF_INIT #define CONFIG_SYS_NAND_ONFI_DETECTION +/* Configuration for Micron MT29F8G08ABACA */ +#define CONFIG_NAND_CHIPSIZE (1 << 30) /* 1GB */ +#define CONFIG_NAND_BLOCKSIZE (1 << 18) /* 256KB */ +#define CONFIG_NAND_PAGE_SHIFT 12 /* 4KiB */ +#define CONFIG_NAND_BLOCK_SHIFT18 /* 256 KiB */ + +/* Configure the Environment and the u-boot-env partition */ +#define MTD_PART_BOOT1_SIZE0x0020 +#define MTD_PART_GPT_SIZE 0x0010 +#define MTD_PART_SSB_SIZE 0x0020 +#define MTD_PART_UBOOT_SIZE0x0020 +#define MTD_PART_UBOOT_ENV_SIZE0x0020 +#define MTD_PART_DTB_SIZE 0x0010 +#define MTD_PART_KERNEL_SIZE 0x0100 +#define MTD_PART_ROOT_SIZE 0x1c00 +/* + * WARNING: When changing the order of the partitions, make sure you update + * CONFIG_ENV_OFFSET accordingly. + */ +#define CONFIG_ENV_IS_IN_NAND +#define CONFIG_ENV_SIZE0x2000 +#define CONFIG_ENV_RANGE (2 * CONFIG_NAND_BLOCKSIZE) +#define CONFIG_ENV_OFFSET (MTD_PART_BOOT1_SIZE + MTD_PART_GPT_SIZE + \ +MTD_PART_SSB_SIZE + MTD_PART_UBOOT_SIZE) +#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_RANGE) +/* + * Check that the u-boot-env partition is big enough to accomodate the + * u-boot environment data and its redundant copy + */ +#if ((2 * CONFIG_ENV_RANGE) > MTD_PART_UBOOT_ENV_SIZE) +#error u-boot-env partition size is to small +#endif + /* MTD configuration */ #define CONFIG_MTD_DEVICE #define CONFIG_MTD_PARTITIONS diff --git a/arch/arm/include/asm/arch-bcmnsp/configs.h b/arch/arm/include/asm/arch-bcmnsp/configs.h index ac4f69e..debccc0 100644 --- a/arch/arm/include/asm/arch-bcmnsp/configs.h +++ b/arch/arm/include/asm/arch-bcmnsp/configs.h @@ -30,6 +30,39 @@ #define CONFIG_SYS_NAND_SELF_INIT #define CONFIG_SYS_NAND_ONFI_DETECTION +/* Configuration for Micron MT29F8G08ABACA */ +#define CONFIG_NAND_CHIPSIZE (1 << 30) /* 1GB */ +#define CONFIG_NAND_BLOCKSIZE (1 << 18) /* 256KB */ +#define CONFIG_NAND_PAGE_SHIFT 12 /* 4KiB */ +#define CONFIG_NAND_BLOCK_SHIFT18 /* 256 KiB */ + +/* Configure the Environment and the u-boot-env partition */ +#define MTD_PART_BOOT1_SIZE0x0020 +#define MTD_PART_GPT_SIZE 0x0010 +#define MTD_PART_SSB_SIZE 0x0020 +#define MTD_PART_UBOOT_SIZE0x0020 +#define MTD_PART_UBOOT_ENV_SIZE0x0020 +#define MTD_PART_DTB_SIZE 0x0010 +#define MTD_PART_KERNEL_SIZE 0x0100 +#define MTD_PART_ROOT_SIZE 0x0c00 +/* + * WARNING: When changing the order of the partitions, make sure you update + * CONFIG_ENV_OFFSET accordingly. + */ +#define CONFIG_ENV_IS_IN_NAND +#define CONFIG_ENV_SIZE0x2000 +#define CONFIG_ENV_RANGE (2 * CONFIG_NAND_BLOCKSIZE) +#define CONFIG_ENV_OFFSET (MTD_PART_BOOT1_SIZE + MTD_PART_GPT_SIZE + \ +MTD_PART_SSB_SIZE + MTD_PART_UBOOT_SIZE) +#define CONFIG_ENV_OFFSET_REDUND (CONFIG_ENV_OFFSET + CONFIG_ENV_RANGE) +/* + * Check that the u-boot-env partition is big enough to accomodate the + * u-boot environment data and its redundant copy + */ +#if ((2 * CONFIG_ENV_RANGE) > MTD_PART_UBOOT_ENV_SIZE) +#error u-boot-env partition size is to small +#endif + /* MTD configuration */ #define CONFIG_MTD_DEVICE #define CONFIG_MTD_PARTITIONS diff --git a/include/configs/bcm_ep_board.h b/include/configs/bcm_ep_board.h index 1d4869b..fe97a40 100644 --- a/include/configs/bcm_ep_board.h +++ b/include/configs/bcm_ep_board.h @@ -50,9 +50,6 @@ #define CONFIG_BAUDRATE115200 -#define CONFIG_ENV_SIZE0x2000 -#define CONFIG_ENV_IS_NOWHERE - #define CONFIG_SYS_NO_FLASH/* Not using NAND/NOR unmanaged flash */ /* console configuration */ -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] arm: bcm: enable MTD support
Enable MTD support on Cygnus and NSP boards. Signed-off-by: Steve Rae --- arch/arm/include/asm/arch-bcmcygnus/configs.h | 6 ++ arch/arm/include/asm/arch-bcmnsp/configs.h| 6 ++ 2 files changed, 12 insertions(+) diff --git a/arch/arm/include/asm/arch-bcmcygnus/configs.h b/arch/arm/include/asm/arch-bcmcygnus/configs.h index 3bf7395..40a9f0e 100644 --- a/arch/arm/include/asm/arch-bcmcygnus/configs.h +++ b/arch/arm/include/asm/arch-bcmcygnus/configs.h @@ -44,4 +44,10 @@ #define CONFIG_SYS_NAND_SELF_INIT #define CONFIG_SYS_NAND_ONFI_DETECTION +/* MTD configuration */ +#define CONFIG_MTD_DEVICE +#define CONFIG_MTD_PARTITIONS +#define CONFIG_CMD_MTDPARTS +#define CONFIG_CMD_MTDPARTS_SPREAD + #endif /* __ARCH_CONFIGS_H */ diff --git a/arch/arm/include/asm/arch-bcmnsp/configs.h b/arch/arm/include/asm/arch-bcmnsp/configs.h index aeaea6a..ac4f69e 100644 --- a/arch/arm/include/asm/arch-bcmnsp/configs.h +++ b/arch/arm/include/asm/arch-bcmnsp/configs.h @@ -30,4 +30,10 @@ #define CONFIG_SYS_NAND_SELF_INIT #define CONFIG_SYS_NAND_ONFI_DETECTION +/* MTD configuration */ +#define CONFIG_MTD_DEVICE +#define CONFIG_MTD_PARTITIONS +#define CONFIG_CMD_MTDPARTS +#define CONFIG_CMD_MTDPARTS_SPREAD + #endif /* __ARCH_CONFIGS_H */ -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] mtd: fix compiler warnings
- add missing declaration
- update debug output format specifiers
Signed-off-by: Steve Rae
---
the checkpatch warning:
warning: cmd/mtdparts.c,1494: quoted string split across lines
is for the existing code; it is not introduced with this change...
cmd/mtdparts.c | 4 ++--
include/linux/mtd/mtd.h | 8
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/cmd/mtdparts.c b/cmd/mtdparts.c
index 86a4689..579eff1 100644
--- a/cmd/mtdparts.c
+++ b/cmd/mtdparts.c
@@ -1491,7 +1491,7 @@ static int spread_partitions(void)
part = list_entry(pentry, struct part_info, link);
debug("spread_partitions: device = %s%d, partition %d ="
- " (%s) 0x%08x@0x%08x\n",
+ " (%s) 0x%08llx@0x%08llx\n",
MTD_DEV_TYPE(dev->id->type), dev->id->num,
part_num, part->name, part->size,
part->offset);
@@ -2009,7 +2009,7 @@ static int do_mtdparts(cmd_tbl_t *cmdtp, int flag, int
argc,
if (!strcmp(&argv[1][3], ".spread")) {
spread_partition(mtd, p, &next_offset);
- debug("increased %s to %d bytes\n", p->name, p->size);
+ debug("increased %s to %llu bytes\n", p->name, p->size);
}
#endif
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 9da77ec..9c36f02 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -495,5 +495,13 @@ int mtd_arg_off(const char *arg, int *idx, loff_t *off,
loff_t *size,
int mtd_arg_off_size(int argc, char *const argv[], int *idx, loff_t *off,
loff_t *size, loff_t *maxsize, int devtype,
uint64_t chipsize);
+
+#ifdef CONFIG_CMD_MTDPARTS_SPREAD
+/* drivers/mtd/mtdcore.c */
+void mtd_get_len_incl_bad(struct mtd_info *mtd, uint64_t offset,
+ const uint64_t length, uint64_t *len_incl_bad,
+ int *truncated);
+#endif /* CONFIG_CMD_MTDPARTS_SPREAD */
+
#endif
#endif /* __MTD_MTD_H__ */
--
1.8.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Anyone else having issues with "fastboot flash" - because of this change?
... updated the subject line, was:
Re: [U-Boot][PATCH v3 1/3] fastboot: OUT transaction length must be
aligned to wMaxPacketSize
On 15-02-24 02:28 AM, Lukasz Majewski wrote:
Hi Dileep,
OUT transactions must be aligned to wMaxPacketSize for each transfer,
or else transfer will not complete successfully. This patch modifies
rx_bytes_expected to return a transfer length that is aligned to
wMaxPacketSize.
Note that the value of wMaxPacketSize and ep->maxpacket may not be
the same value, and it is the value of wMaxPacketSize that should be
used for alignment. wMaxPacketSize is passed depending on the speed of
connection.
Signed-off-by: Dileep Katta
---
Changes in v2:
- Corrected source of wMaxPacketSize
Changes in v3:
- Corrected the logic to accomodate both HS and FS speeds
drivers/usb/gadget/f_fastboot.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/f_fastboot.c
b/drivers/usb/gadget/f_fastboot.c index a8d8205..2793590 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -55,6 +55,7 @@ static inline struct f_fastboot
*func_to_fastboot(struct usb_function *f) static struct f_fastboot
*fastboot_func; static unsigned int download_size;
static unsigned int download_bytes;
+static bool is_high_speed;
static struct usb_endpoint_descriptor fs_ep_in = {
.bLength= USB_DT_ENDPOINT_SIZE,
@@ -219,10 +220,13 @@ static int fastboot_set_alt(struct usb_function
*f, __func__, f->name, interface, alt);
/* make sure we don't enable the ep twice */
- if (gadget->speed == USB_SPEED_HIGH)
+ if (gadget->speed == USB_SPEED_HIGH) {
ret = usb_ep_enable(f_fb->out_ep, &hs_ep_out);
- else
+ is_high_speed = true;
+ } else {
ret = usb_ep_enable(f_fb->out_ep, &fs_ep_out);
+ is_high_speed = false;
+ }
if (ret) {
puts("failed to enable out ep\n");
return ret;
@@ -370,13 +374,20 @@ static void cb_getvar(struct usb_ep *ep, struct
usb_request *req) fastboot_tx_write_str(response);
}
-static unsigned int rx_bytes_expected(void)
+static unsigned int rx_bytes_expected(unsigned int maxpacket)
{
int rx_remain = download_size - download_bytes;
+ int rem = 0;
if (rx_remain < 0)
return 0;
if (rx_remain > EP_BUFFER_SIZE)
return EP_BUFFER_SIZE;
+ if (rx_remain < maxpacket) {
+ rx_remain = maxpacket;
+ } else if (rx_remain % maxpacket != 0) {
+ rem = rx_remain % maxpacket;
+ rx_remain = rx_remain + (maxpacket - rem);
+ }
Is anyone else having problems with this code???
I need to remove these six (newly added) lines in order to get my boards
to work -- otherwise, they just "hang" druing the download phase of
"fastboot flash"
Thanks in advance, Steve
return rx_remain;
}
@@ -388,6 +399,7 @@ static void rx_handler_dl_image(struct usb_ep
*ep, struct usb_request *req) const unsigned char *buffer = req->buf;
unsigned int buffer_size = req->actual;
unsigned int pre_dot_num, now_dot_num;
+ unsigned int max;
if (req->status != 0) {
printf("Bad status: %d\n", req->status);
@@ -425,7 +437,9 @@ static void rx_handler_dl_image(struct usb_ep
*ep, struct usb_request *req)
printf("\ndownloading of %d bytes finished\n",
download_bytes); } else {
- req->length = rx_bytes_expected();
+ max = is_high_speed ? hs_ep_out.wMaxPacketSize :
+ fs_ep_out.wMaxPacketSize;
+ req->length = rx_bytes_expected(max);
if (req->length < ep->maxpacket)
req->length = ep->maxpacket;
}
@@ -438,6 +452,7 @@ static void cb_download(struct usb_ep *ep, struct
usb_request *req) {
char *cmd = req->buf;
char response[RESPONSE_LEN];
+ unsigned int max;
strsep(&cmd, ":");
download_size = simple_strtoul(cmd, NULL, 16);
@@ -453,7 +468,9 @@ static void cb_download(struct usb_ep *ep, struct
usb_request *req) } else {
sprintf(response, "DATA%08x", download_size);
req->complete = rx_handler_dl_image;
- req->length = rx_bytes_expected();
+ max = is_high_speed ? hs_ep_out.wMaxPacketSize :
+ fs_ep_out.wMaxPacketSize;
+ req->length = rx_bytes_expected(max);
if (req->length < ep->maxpacket)
req->length = ep->maxpacket;
}
Applied to u-boot-dfu branch.
Thanks for the patch!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] usb: Remove 200 ms delay in usb_hub_port_connect_change()
On 03/10/2016 08:50 AM, Stefan Roese wrote: This patch removes 2 mdelay(200) calls from usb_hub_port_connect_change(). These delays don't seem to be necessary. At least not in my tests. Here the number for a custom x86 Bay Trail board (not in mainline yet) with a quite large and complex USB hub infrastructure. Without this patch: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 28.415 seconds With this patch: starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 24.811 seconds So ~3.5 seconds of USB scanning time reduction. These mdelay calls are removed if CONFIG_USB_FAST_SCAN is defined. They are not removed per default yet. It would be good to test with this option enabled on many other boards. And once we have a good testing base we can decide to remove these delays completely, including this macro. This patch, Tested-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] usb: legacy_hub_port_reset(): Speedup hub reset handling
On 03/10/2016 08:50 AM, Stefan Roese wrote: Start with a short USB hub reset delay of 10ms. This can be enough for some configurations. The 2nd delay at the of the loop is completely removed. Since the delay hasn't been long enough, a longer delay time of 200ms is assigned. And will be used in the next loop round. This hub reset handling is also used in the v4.4 Linux USB driver, hub_port_reset(). This patch, Tested-by: Stephen Warren (Tested with 1 USB SD card reader, 1 USB Ethernet dongle, 4 USB flash drives, which IIRC includes some of the problematic devices that triggered previous changes to the USB enumeration code in U-Boot) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] usb: Don't reset the USB hub a 2nd time
On 03/10/2016 08:50 AM, Stefan Roese wrote: Debugging has shown, that all USB hubs are being resetted twice while USB scanning. This introduces additional delays and makes USB scanning even more slow. Testing has shown that this 2nd USB hub reset doesn't seem to be necessary. This patch now removes this 2nd USB hub reset if CONFIG_USB_FAST_SCAN is defined. Resulting in faster USB scan time. Here the current number: Without this patch: => time usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 6.319 seconds With this patch: => time usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 9 USB Device(s) found time: 3.777 seconds So ~2.5 seconds of USB scanning time reduction. Again, this 2nd reset is only removed if CONFIG_USB_FAST_SCAN is defined. Once more tests are done on multiple other platforms we can decide to remove this 2nd reset completely. This patch, after modifying the patch to unconditionally remove the code rather than only conditionally, Tested-by: Stephen Warren For the other patches I agree with Hans' comments. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Anyone else having issues with "fastboot flash" - because of this change?
On Thu, Mar 10, 2016 at 3:46 PM, Steve Rae wrote:
> ... updated the subject line, was:
> Re: [U-Boot][PATCH v3 1/3] fastboot: OUT transaction length must be aligned
> to wMaxPacketSize
>
>
>>> -static unsigned int rx_bytes_expected(void)
>>> +static unsigned int rx_bytes_expected(unsigned int maxpacket)
>>> {
>>> int rx_remain = download_size - download_bytes;
>>> + int rem = 0;
>>> if (rx_remain < 0)
>>> return 0;
>>> if (rx_remain > EP_BUFFER_SIZE)
>>> return EP_BUFFER_SIZE;
>>> + if (rx_remain < maxpacket) {
>>> + rx_remain = maxpacket;
>>> + } else if (rx_remain % maxpacket != 0) {
>>> + rem = rx_remain % maxpacket;
>>> + rx_remain = rx_remain + (maxpacket - rem);
>>> + }
>
>
> Is anyone else having problems with this code???
> I need to remove these six (newly added) lines in order to get my boards to
> work -- otherwise, they just "hang" druing the download phase of "fastboot
> flash"
>
> Thanks in advance, Steve
>
MORE INFO:
I added some logs to see what is happening:
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index f87aae7..824430f 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -427,12 +427,17 @@ static unsigned int rx_bytes_expected(unsigned
int maxpacket)
return 0;
if (rx_remain > EP_BUFFER_SIZE)
return EP_BUFFER_SIZE;
+#if 1
if (rx_remain < maxpacket) {
+ printf("\nVALIDATE: %s: %d (%d) %d\n", __func__,
rx_remain, maxpacket, maxpacket);
rx_remain = maxpacket;
} else if (rx_remain % maxpacket != 0) {
rem = rx_remain % maxpacket;
+ printf("\nVALIDATE: %s: %d (%d) %d %d\n", __func__,
rx_remain, maxpacket, rem, rx_remain + (maxpacket - rem));
rx_remain = rx_remain + (maxpacket - rem);
}
+#endif
+ printf("\nVALIDATE: using %d\n", rx_remain);
return rx_remain;
}
RESULTS:
In the case that fails, (#if 1), it reports:
VALIDATE: rx_bytes_expected: 812 (512) 300 1024
VALIDATE: using 1024
In the case that works (#if 0), it reports:
VALIDATE: using 812
To me, it looks like there is only 812 bytes more to be downloaded,
but this code modifies that value to expect 1024 bytes;
and I guess it hangs after the 812 have been received (while waiting
for the rest of the 1024)
Please advise!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sf: Correct data types in stm_is_locked_sr()
The stm_is_locked_sr() function is picked from Linux kernel. For reason
unknown, the 64bit data types used by the function and present in Linux
were replaced with 32bit unsigned ones, which causes trouble.
The testcase performed was done using ST M25P80 chip.
The command used was:
=> sf protect unlock 0 0x1
The call chain starts in stm_unlock(), which calls stm_is_locked_sr()
with negative ofs argument. This works fine in Linux, where the "ofs"
is loff_t, which is signed long long, while this fails in U-Boot, where
"ofs" is u32 (unsigned int). Because of this signedness problem, the
expression past the return statement to be incorrectly evaluated to 1,
which in turn propagates back to stm_unlock() and results in -EINVAL.
The correction is very simple, just use the correctly sized data types
with correct signedness in the function to make it work as intended.
Signed-off-by: Marek Vasut
Cc: Simon Glass
Cc: Jagan Teki
---
drivers/mtd/spi/spi_flash.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 2ae2e3c..44d9e9b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -665,7 +665,7 @@ int sst_write_bp(struct spi_flash *flash, u32 offset,
size_t len,
#if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST)
static void stm_get_locked_range(struct spi_flash *flash, u8 sr, loff_t *ofs,
-u32 *len)
+u64 *len)
{
u8 mask = SR_BP2 | SR_BP1 | SR_BP0;
int shift = ffs(mask) - 1;
@@ -685,11 +685,11 @@ static void stm_get_locked_range(struct spi_flash *flash,
u8 sr, loff_t *ofs,
/*
* Return 1 if the entire region is locked, 0 otherwise
*/
-static int stm_is_locked_sr(struct spi_flash *flash, u32 ofs, u32 len,
+static int stm_is_locked_sr(struct spi_flash *flash, loff_t ofs, u64 len,
u8 sr)
{
loff_t lock_offs;
- u32 lock_len;
+ u64 lock_len;
stm_get_locked_range(flash, sr, &lock_offs, &lock_len);
--
2.7.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] x86: Support booting SeaBIOS
On Tue, Mar 1, 2016 at 10:04 AM, Simon Glass wrote: > On 29 February 2016 at 00:54, Bin Meng wrote: >> SeaBIOS is an open source implementation of a 16-bit x86 BIOS. >> It can run in an emulator or natively on x86 hardware with the >> use of coreboot. With SeaBIOS's help, we can boot some OSes >> that require 16-bit BIOS services like Windows/DOS. >> >> As U-Boot, we have to manually create a table where SeaBIOS gets >> system information (eg: E820) from. The table unfortunately has >> to follow the coreboot table format as SeaBIOS currently supports >> booting as a coreboot payload. >> >> Signed-off-by: Bin Meng >> --- >> >> Changes in v2: None >> >> arch/x86/Kconfig | 10 ++ >> arch/x86/include/asm/tables.h | 3 +++ >> arch/x86/lib/tables.c | 15 +++ >> 3 files changed, 28 insertions(+) > > Reviewed-by: Simon Glass applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] x86: qemu: Enable ACPI table generation by default
On Mon, Feb 29, 2016 at 3:54 PM, Bin Meng wrote: > Now that ACPI is supported on QEMU, enable it. > > Signed-off-by: Bin Meng > Reviewed-by: Simon Glass > --- > > Changes in v2: None > > configs/qemu-x86_defconfig | 1 + > 1 file changed, 1 insertion(+) > applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] x86: Document how to play with SeaBIOS
On Mon, Feb 29, 2016 at 3:54 PM, Bin Meng wrote: > Boting SeaBIOS is done via U-Boot's bootelf command. Document this. > > Signed-off-by: Bin Meng > Reviewed-by: Simon Glass > > --- > > Changes in v2: > - Drop patches which were already applied > - Add more detailed information for testing QEMU/SeaBIOS > (eg: how to create 'disk.img') > > doc/README.x86 | 57 +++-- > 1 file changed, 55 insertions(+), 2 deletions(-) > applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/69] dm: timer: Correct timer init ordering after relocation
Hi Simon, On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: > Commit 1057e6c broke use of the timer with driver model. If the timer is used > before relocation, then it becomes broken after relocation. This prevents > some x86 boards from booting. Fix it. Isn't the broken due to gd not initialized to zero? > > Fixes: 1057e6c (timer: Set up the real timer after driver model is available) > > Signed-off-by: Simon Glass > --- > > common/board_r.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/common/board_r.c b/common/board_r.c > index 52a9b26..0f068bf 100644 > --- a/common/board_r.c > +++ b/common/board_r.c > @@ -318,11 +318,13 @@ static int initr_dm(void) > /* Save the pre-reloc driver model and start a new one */ > gd->dm_root_f = gd->dm_root; > gd->dm_root = NULL; > +#ifdef CONFIG_TIMER > + gd->timer = NULL; > +#endif > ret = dm_init_and_scan(false); > if (ret) > return ret; > #ifdef CONFIG_TIMER_EARLY > - gd->timer = NULL; > ret = dm_timer_init(); > if (ret) > return ret; > -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/69] syscon: Avoid returning a device on failure
Hi Simon, On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: > If the device cannot be probed, syscon_get_by_driver_data() will still > return a useful value in its devp parameter. Ensure that it returns NULL > instead. Shouldn't this be the caller's bug, that caller must check the return value? > > Signed-off-by: Simon Glass > --- > > drivers/core/syscon-uclass.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/core/syscon-uclass.c b/drivers/core/syscon-uclass.c > index a0666d0..e03f46a 100644 > --- a/drivers/core/syscon-uclass.c > +++ b/drivers/core/syscon-uclass.c > @@ -38,6 +38,7 @@ int syscon_get_by_driver_data(ulong driver_data, struct > udevice **devp) > struct uclass *uc; > int ret; > > + *devp = NULL; > ret = uclass_get(UCLASS_SYSCON, &uc); > if (ret) > return ret; > -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/69] gpio: Use const where possible
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: > Some functions do not change the struct gpio_desc parameter. Update these to > use const so this is clear. > > Signed-off-by: Simon Glass > --- > > drivers/gpio/gpio-uclass.c | 10 +- > include/asm-generic/gpio.h | 10 +- > 2 files changed, 10 insertions(+), 10 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/69] pci: Correct a few comments and nits
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: > Two comments are missing a parameter and there is an extra blank line. Also > two of the region access macros are misnamed. Correct these problems. > > Signed-off-by: Simon Glass > --- > > drivers/pci/pci-uclass.c | 1 - > include/pci.h| 6 -- > 2 files changed, 4 insertions(+), 3 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/69] cpu: Add support for microcode version and CPU ID
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: > Some CPUs use microcode and each core can have a different version of > microcode loaded. Also some CPUs support the concept of an integer ID used > for identification purposes. Add support for these in the CPU uclass. > > Signed-off-by: Simon Glass > --- > > cmd/cpu.c | 7 +++ > include/cpu.h | 5 + > 2 files changed, 12 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/69] pci: Add functions to update PCI configuration registers
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: > It is common to read a config register value, clear and set some bits, then > write back the updated value. Add functions to do this in one step, for > convenience. > > Signed-off-by: Simon Glass > --- > > drivers/pci/pci-uclass.c | 57 > > include/pci.h| 23 +++ > 2 files changed, 80 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/69] gpio: Add a function to obtain a GPIO vector value
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: > We can use GPIOs as binary digits for reading 'strapping' values. Each GPIO > is assigned a single bit and can be set high or low on the circuit board. We > already have a legacy function for reading these values. Add one that > supports driver model. > > Signed-off-by: Simon Glass > --- > > drivers/gpio/gpio-uclass.c | 18 ++ > include/asm-generic/gpio.h | 12 > 2 files changed, 30 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] exynos5: common: Enable CONFIG_USB_ETHER_RTL8152 ethernet support
On 05/03/16 18:08, Anand Moon wrote: > Enable CONFIG_USB_ETHER_RTL8152 support for Odroid XU4 which > has support for RTL8153-CG gigabit Ethernet adapter, > connected over USB 3.0. > > commit 9dc8ba19c50fc0b1623c654bcfe6caa903a4c36c added support > for Realtek 8152/8153 driver. > > Signed-off-by: Anand Moon > --- > Depends on: > https://patchwork.ozlabs.org/patch/548453/ > --- > include/configs/exynos5-common.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/configs/exynos5-common.h > b/include/configs/exynos5-common.h > index 834a22f..5a7915c 100644 > --- a/include/configs/exynos5-common.h > +++ b/include/configs/exynos5-common.h > @@ -170,6 +170,7 @@ > #define CONFIG_USB_HOST_ETHER > #define CONFIG_USB_ETHER_ASIX > #define CONFIG_USB_ETHER_SMSC95XX > +#define CONFIG_USB_ETHER_RTL8152 > > /* USB boot mode */ > #define CONFIG_USB_BOOTING > applied to u-boot-samsung. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/69] video: Allow simple-panel to be used without regulators
On Mon, Mar 7, 2016 at 3:37 PM, Anatolij Gustschin wrote: > Hi Simon, > > On Sun, 6 Mar 2016 19:27:48 -0700 > Simon Glass s...@chromium.org wrote: > >> At present simple-panel requires regulator support and will not build >> without it. But some panels do not have a power supply, or at least not one >> that can be controlled. Update the implementation to cope with this. >> >> Signed-off-by: Simon Glass > > Acked-by: Anatolij Gustschin applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/69] gpio: Use const where possible
On Fri, Mar 11, 2016 at 11:45 AM, Bin Meng wrote: > On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: >> Some functions do not change the struct gpio_desc parameter. Update these to >> use const so this is clear. >> >> Signed-off-by: Simon Glass >> --- >> >> drivers/gpio/gpio-uclass.c | 10 +- >> include/asm-generic/gpio.h | 10 +- >> 2 files changed, 10 insertions(+), 10 deletions(-) >> > > Reviewed-by: Bin Meng applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/69] cpu: Add support for microcode version and CPU ID
On Fri, Mar 11, 2016 at 11:45 AM, Bin Meng wrote: > On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: >> Some CPUs use microcode and each core can have a different version of >> microcode loaded. Also some CPUs support the concept of an integer ID used >> for identification purposes. Add support for these in the CPU uclass. >> >> Signed-off-by: Simon Glass >> --- >> >> cmd/cpu.c | 7 +++ >> include/cpu.h | 5 + >> 2 files changed, 12 insertions(+) >> > > Reviewed-by: Bin Meng applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/69] gpio: Add a function to obtain a GPIO vector value
On Fri, Mar 11, 2016 at 11:45 AM, Bin Meng wrote: > On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: >> We can use GPIOs as binary digits for reading 'strapping' values. Each GPIO >> is assigned a single bit and can be set high or low on the circuit board. We >> already have a legacy function for reading these values. Add one that >> supports driver model. >> >> Signed-off-by: Simon Glass >> --- >> >> drivers/gpio/gpio-uclass.c | 18 ++ >> include/asm-generic/gpio.h | 12 >> 2 files changed, 30 insertions(+) >> > > Reviewed-by: Bin Meng applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/69] pci: Add functions to update PCI configuration registers
On Fri, Mar 11, 2016 at 11:46 AM, Bin Meng wrote: > On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: >> It is common to read a config register value, clear and set some bits, then >> write back the updated value. Add functions to do this in one step, for >> convenience. >> >> Signed-off-by: Simon Glass >> --- >> >> drivers/pci/pci-uclass.c | 57 >> >> include/pci.h| 23 +++ >> 2 files changed, 80 insertions(+) >> > > Reviewed-by: Bin Meng applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/69] pci: Correct a few comments and nits
On Fri, Mar 11, 2016 at 11:46 AM, Bin Meng wrote: > On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: >> Two comments are missing a parameter and there is an extra blank line. Also >> two of the region access macros are misnamed. Correct these problems. >> >> Signed-off-by: Simon Glass >> --- >> >> drivers/pci/pci-uclass.c | 1 - >> include/pci.h| 6 -- >> 2 files changed, 4 insertions(+), 3 deletions(-) >> > > Reviewed-by: Bin Meng applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/69] input: i8042: Make sure the keyboard is enabled
Hi Simon,
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> Add one more step into the init sequence. This fixes the keyboard on samus,
> which otherwise does not work.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/input/i8042.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
> index 661d7fd..12f8934 100644
> --- a/drivers/input/i8042.c
> +++ b/drivers/input/i8042.c
> @@ -128,6 +128,12 @@ static int kbd_reset(int quirk)
> if (kbd_cmd_read(CMD_SELF_TEST) != KBC_TEST_OK)
> goto err;
>
> + if (kbd_write(I8042_DATA_REG, 0xf4) ||
We should use macro for 0xf4. 0xf4 is a command to drain output
buffer, but the debug printf says "enable failed"? It's not a keyboard
enable command. And I suspect this command should be put after sending
CMD_RESET_KBD, which is a more natural sequence. Can you try that?
> + kbd_read(I8042_DATA_REG) != KBD_ACK) {
> + debug("Keyboard enable failed ACK\n");
> + goto err;
> + }
> +
> /* keyboard reset */
> if (kbd_write(I8042_DATA_REG, CMD_RESET_KBD) ||
> kbd_read(I8042_DATA_REG) != KBD_ACK ||
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/69] malloc_simple: Add a little more debugging
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: > Output the pointer returned by each call to malloc(). This can be useful > when debugging memory problems. > > Signed-off-by: Simon Glass > --- > > common/malloc_simple.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/69] x86: Allow use of serial soon after relocation
Hi Simon,
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> At present on x86 machines with use cache-as-RAM, the memory goes away just
> before board_init_r() is called. This means that serial drivers are
> no-longer unavailable, until initr_dm() it called, etc.
>
> Any attempt to use printf() within this period will cause a hang.
>
> To fix this, mark the serial devices as 'unavailable' when it is no-longer
> available. Bring it back when serial_initialize() is called. This means that
> the debug UART will be used instead for this period.
>
> Signed-off-by: Simon Glass
> ---
>
> common/board_f.c | 7 +++
> drivers/serial/serial-uclass.c | 1 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/common/board_f.c b/common/board_f.c
> index 622093a..109025a 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -1096,6 +1096,13 @@ void board_init_f_r(void)
> hang();
>
> /*
> +* The pre-relocation drivers may be using memory that has now gone
> +* away. Mark serial as unavailable - this will fall back to the debug
> +* UART if available.
> +*/
> + gd->flags &= ~GD_FLG_SERIAL_READY;
> +
What about other architectures (non-X86 and non-ARC)?
> + /*
> * U-Boot has been copied into SDRAM, the BSS has been cleared etc.
> * Transfer execution from Flash to RAM by calculating the address
> * of the in-RAM copy of board_init_r() and calling it
> diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
> index 1c447ff..6562be0 100644
> --- a/drivers/serial/serial-uclass.c
> +++ b/drivers/serial/serial-uclass.c
> @@ -116,6 +116,7 @@ int serial_init(void)
> void serial_initialize(void)
> {
> serial_find_console_or_panic();
> + gd->flags |= GD_FLG_SERIAL_READY;
I think we can simply replace this to:
void serial_initialize(void)
{
serial_init();
}
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/69] x86: cpu: Make the vendor table const
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: > This does not need to be modified at run-time, so make it const. > > Signed-off-by: Simon Glass > --- > > arch/x86/cpu/cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/69] x86: cpu: Add functions to return the family and stepping
Hi Simon,
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> These two identifiers can be useful for drivers which need to adjust their
> behaviour depending on the CPU family or stepping (revision).
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/cpu.c | 10 ++
> arch/x86/include/asm/cpu.h | 14 ++
> 2 files changed, 24 insertions(+)
>
> diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
> index 8800e09..e2aad19 100644
> --- a/arch/x86/cpu/cpu.c
> +++ b/arch/x86/cpu/cpu.c
> @@ -333,6 +333,16 @@ static inline void get_fms(struct cpuinfo_x86 *c,
> uint32_t tfms)
> c->x86_model += ((tfms >> 16) & 0xF) << 4;
> }
>
> +u32 cpu_get_family_model(void)
> +{
> + return gd->arch.x86_device & 0x0fff0ff0;
The decrypted family and model are stored in gd->arch.x86 and
gd->arch.x86_model. Returning raw data would still need the caller to
parse it. Why not just return these directly?
> +}
> +
> +u32 cpu_get_stepping(void)
> +{
> + return gd->arch.x86_device & 0xf;
This is gd->arch.x86_mask.
> +}
> +
> int x86_cpu_init_f(void)
> {
> const u32 em_rst = ~X86_CR0_EM;
> diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
> index 18b0345..987dc65 100644
> --- a/arch/x86/include/asm/cpu.h
> +++ b/arch/x86/include/asm/cpu.h
> @@ -260,4 +260,18 @@ void cpu_call32(ulong code_seg32, ulong target, ulong
> table);
> */
> int cpu_jump_to_64bit(ulong setup_base, ulong target);
>
> +/**
> + * cpu_get_family_model() - Get the family and model for the CPU
> + *
> + * @return the CPU ID masked with 0x0fff0ff0
> + */
> +u32 cpu_get_family_model(void);
> +
> +/**
> + * cpu_get_stepping() - Get the stepping value for the CPU
> + *
> + * @return the CPU ID masked with 0xf
> + */
> +u32 cpu_get_stepping(void);
> +
> #endif
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/69] x86: Move cache-as-RAM code into a common location
On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote:
> This cache-as-RAM (CAR) code is common to several Intel chips. Create a new
> intel_common directory and move it in there.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/Makefile | 1 +
> arch/x86/cpu/intel_common/Makefile | 7 +++
> arch/x86/cpu/{ivybridge => intel_common}/car.S | 0
> arch/x86/cpu/ivybridge/Makefile| 1 -
> 4 files changed, 8 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/cpu/intel_common/Makefile
> rename arch/x86/cpu/{ivybridge => intel_common}/car.S (100%)
>
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 19/69] x86: Add the root-complex block to common intel registers
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote: > This is similar to MCH in that it is used in various drivers. Add it to > the common header. > > Signed-off-by: Simon Glass > --- > > arch/x86/cpu/ivybridge/bd82x6x.c | 1 + > arch/x86/cpu/ivybridge/lpc.c | 6 -- > arch/x86/include/asm/arch-ivybridge/pch.h | 5 - > arch/x86/include/asm/intel_regs.h | 4 > 4 files changed, 9 insertions(+), 7 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/69] x86: Create a common header for Intel register access
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> There are several blocks of registers that are accessed from all over the
> code on Intel CPUs. These don't currently have their own driver and it is
> not clear whether having a driver makes sense.
>
> An example is the Memory Controller Hub (MCH). We map it to a known location
> on some Intel chips (mostly those without FSP - Firmware Support Package).
>
> Add a new header file for these registers, and move MCH into it.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/ivybridge/cpu.c | 1 +
> arch/x86/cpu/ivybridge/gma.c | 1 +
> arch/x86/cpu/ivybridge/northbridge.c | 5 +++--
> arch/x86/cpu/ivybridge/sdram.c| 3 ++-
> arch/x86/include/asm/arch-ivybridge/sandybridge.h | 3 ---
> arch/x86/include/asm/intel_regs.h | 15 +++
> 6 files changed, 22 insertions(+), 6 deletions(-)
> create mode 100644 arch/x86/include/asm/intel_regs.h
>
> diff --git a/arch/x86/cpu/ivybridge/cpu.c b/arch/x86/cpu/ivybridge/cpu.c
> index c54e800..f847a2f 100644
> --- a/arch/x86/cpu/ivybridge/cpu.c
> +++ b/arch/x86/cpu/ivybridge/cpu.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/arch/x86/cpu/ivybridge/gma.c b/arch/x86/cpu/ivybridge/gma.c
> index 3b6291e..87e06e7 100644
> --- a/arch/x86/cpu/ivybridge/gma.c
> +++ b/arch/x86/cpu/ivybridge/gma.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/arch/x86/cpu/ivybridge/northbridge.c
> b/arch/x86/cpu/ivybridge/northbridge.c
> index a066607..f7e0bc3 100644
> --- a/arch/x86/cpu/ivybridge/northbridge.c
> +++ b/arch/x86/cpu/ivybridge/northbridge.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -167,8 +168,8 @@ static void sandybridge_setup_northbridge_bars(struct
> udevice *dev)
> debug("Setting up static registers\n");
> dm_pci_write_config32(dev, EPBAR, DEFAULT_EPBAR | 1);
> dm_pci_write_config32(dev, EPBAR + 4, (0LL + DEFAULT_EPBAR) >> 32);
> - dm_pci_write_config32(dev, MCHBAR, DEFAULT_MCHBAR | 1);
> - dm_pci_write_config32(dev, MCHBAR + 4, (0LL + DEFAULT_MCHBAR) >> 32);
> + dm_pci_write_config32(dev, MCHBAR, MCH_BASE_ADDRESS | 1);
> + dm_pci_write_config32(dev, MCHBAR + 4, (0LL + MCH_BASE_ADDRESS) >>
> 32);
> /* 64MB - busses 0-63 */
> dm_pci_write_config32(dev, PCIEXBAR, DEFAULT_PCIEXBAR | 5);
> dm_pci_write_config32(dev, PCIEXBAR + 4,
> diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
> index e23c422..6f45071 100644
> --- a/arch/x86/cpu/ivybridge/sdram.c
> +++ b/arch/x86/cpu/ivybridge/sdram.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -682,7 +683,7 @@ int dram_init(void)
> {
> struct pei_data pei_data __aligned(8) = {
> .pei_version = PEI_VERSION,
> - .mchbar = DEFAULT_MCHBAR,
> + .mchbar = MCH_BASE_ADDRESS,
> .dmibar = DEFAULT_DMIBAR,
> .epbar = DEFAULT_EPBAR,
> .pciexbar = CONFIG_PCIE_ECAM_BASE,
> diff --git a/arch/x86/include/asm/arch-ivybridge/sandybridge.h
> b/arch/x86/include/asm/arch-ivybridge/sandybridge.h
> index d137d67..59b05cc 100644
> --- a/arch/x86/include/asm/arch-ivybridge/sandybridge.h
> +++ b/arch/x86/include/asm/arch-ivybridge/sandybridge.h
> @@ -38,7 +38,6 @@
> #define IED_SIZE 0x40
>
> /* Northbridge BARs */
> -#define DEFAULT_MCHBAR 0xfed1 /* 16 KB */
> #define DEFAULT_DMIBAR 0xfed18000 /* 4 KB */
> #define DEFAULT_EPBAR 0xfed19000 /* 4 KB */
> #define DEFAULT_RCBABASE 0xfed1c000
> @@ -97,8 +96,6 @@
> /*
> * MCHBAR
> */
> -#define MCHBAR_REG(reg)(DEFAULT_MCHBAR + (reg))
> -
> #define SSKPD 0x5d14 /* 16bit (scratchpad) */
> #define BIOS_RESET_CPL 0x5da8 /* 8bit */
>
> diff --git a/arch/x86/include/asm/intel_regs.h
> b/arch/x86/include/asm/intel_regs.h
> new file mode 100644
> index 000..61e0ec2
> --- /dev/null
> +++ b/arch/x86/include/asm/intel_regs.h
> @@ -0,0 +1,15 @@
> +/*
> + * Copyright (c) 2016 Google, Inc
> + *
> + * SPDX-License-Identifier:GPL-2.0
nits: GPL-2.0+?
> + */
> +
> +#ifndef __asm_intel_regs_h
> +#define __asm_intel_regs_h
nits: all capital letters
> +
> +/* Access the memory-controller hub */
> +#define MCH_BASE_ADDRESS 0xfed1
> +#define MCH_BASE_SIZE 0x8000
> +#define MCHBAR_REG(reg)(MCH_BASE_ADDRESS + (reg))
> +
> +#endif
> --
Reviewed-by: Bin Meng
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 17/69] x86: Move microcode code to a common location
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> This code is used on several Intel CPUs. Move it into a common location.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/intel_common/Makefile | 3 +++
> arch/x86/cpu/intel_common/car.S| 2 +-
> arch/x86/cpu/{ivybridge => intel_common}/microcode_intel.c | 4 +++-
I would rename this to just "microcode.c" since the directory already
indicates "intel_common".
> arch/x86/cpu/ivybridge/Makefile| 1 -
> arch/x86/cpu/ivybridge/cpu.c | 2 +-
> arch/x86/include/asm/{arch-ivybridge => }/microcode.h | 0
> 6 files changed, 8 insertions(+), 4 deletions(-)
> rename arch/x86/cpu/{ivybridge => intel_common}/microcode_intel.c (98%)
> rename arch/x86/include/asm/{arch-ivybridge => }/microcode.h (100%)
>
> diff --git a/arch/x86/cpu/intel_common/Makefile
> b/arch/x86/cpu/intel_common/Makefile
> index 5dd9573..bc7c3ff 100644
> --- a/arch/x86/cpu/intel_common/Makefile
> +++ b/arch/x86/cpu/intel_common/Makefile
> @@ -5,3 +5,6 @@
> #
>
> obj-$(CONFIG_HAVE_MRC) += car.o
> +ifndef CONFIG_TARGET_EFI
> +obj-y += microcode_intel.o
> +endif
> diff --git a/arch/x86/cpu/intel_common/car.S b/arch/x86/cpu/intel_common/car.S
> index 1defabf..81ac976 100644
> --- a/arch/x86/cpu/intel_common/car.S
> +++ b/arch/x86/cpu/intel_common/car.S
> @@ -12,12 +12,12 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> -#include
>
> #define MTRR_PHYS_BASE_MSR(reg) (0x200 + 2 * (reg))
> #define MTRR_PHYS_MASK_MSR(reg) (0x200 + 2 * (reg) + 1)
> diff --git a/arch/x86/cpu/ivybridge/microcode_intel.c
> b/arch/x86/cpu/intel_common/microcode_intel.c
> similarity index 98%
> rename from arch/x86/cpu/ivybridge/microcode_intel.c
> rename to arch/x86/cpu/intel_common/microcode_intel.c
> index 2440a97..3054fab 100644
> --- a/arch/x86/cpu/ivybridge/microcode_intel.c
> +++ b/arch/x86/cpu/intel_common/microcode_intel.c
> @@ -12,10 +12,12 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> -#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
>
> /**
> * struct microcode_update - standard microcode header from Intel
> diff --git a/arch/x86/cpu/ivybridge/Makefile b/arch/x86/cpu/ivybridge/Makefile
> index b117f0d..78006f1 100644
> --- a/arch/x86/cpu/ivybridge/Makefile
> +++ b/arch/x86/cpu/ivybridge/Makefile
> @@ -13,7 +13,6 @@ obj-y += gma.o
> obj-y += lpc.o
> obj-y += me_status.o
> obj-y += model_206ax.o
> -obj-y += microcode_intel.o
> obj-y += northbridge.o
> obj-y += report_platform.o
> obj-y += sata.o
> diff --git a/arch/x86/cpu/ivybridge/cpu.c b/arch/x86/cpu/ivybridge/cpu.c
> index 948833c..c54e800 100644
> --- a/arch/x86/cpu/ivybridge/cpu.c
> +++ b/arch/x86/cpu/ivybridge/cpu.c
> @@ -19,13 +19,13 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> -#include
> #include
> #include
>
> diff --git a/arch/x86/include/asm/arch-ivybridge/microcode.h
> b/arch/x86/include/asm/microcode.h
> similarity index 100%
> rename from arch/x86/include/asm/arch-ivybridge/microcode.h
> rename to arch/x86/include/asm/microcode.h
> --
Other than that,
Reviewed-by: Bin Meng
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/69] x86: Move common LPC code to its own place
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Some of the LPC code is common to several Intel LPC devices. Move it into a
> common location.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/intel_common/Makefile| 1 +
> arch/x86/cpu/intel_common/lpc_common.c| 102
> ++
> arch/x86/cpu/ivybridge/bd82x6x.c | 16 +
> arch/x86/cpu/ivybridge/lpc.c | 73 ++---
> arch/x86/include/asm/arch-ivybridge/pch.h | 2 -
> arch/x86/include/asm/lpc_common.h | 59 +
> 6 files changed, 168 insertions(+), 85 deletions(-)
> create mode 100644 arch/x86/cpu/intel_common/lpc_common.c
> create mode 100644 arch/x86/include/asm/lpc_common.h
>
> diff --git a/arch/x86/cpu/intel_common/Makefile
> b/arch/x86/cpu/intel_common/Makefile
> index bc7c3ff..36c150d 100644
> --- a/arch/x86/cpu/intel_common/Makefile
> +++ b/arch/x86/cpu/intel_common/Makefile
> @@ -5,6 +5,7 @@
> #
>
> obj-$(CONFIG_HAVE_MRC) += car.o
> +obj-y += lpc_common.o
> ifndef CONFIG_TARGET_EFI
> obj-y += microcode_intel.o
> endif
> diff --git a/arch/x86/cpu/intel_common/lpc_common.c
> b/arch/x86/cpu/intel_common/lpc_common.c
> new file mode 100644
> index 000..2a3b941
> --- /dev/null
> +++ b/arch/x86/cpu/intel_common/lpc_common.c
> @@ -0,0 +1,102 @@
> +/*
> + * Copyright (c) 2016 Google, Inc
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/*
> + * Enable Prefetching and Caching.
> + */
nits: single-line comment format
> +static void enable_spi_prefetch(struct udevice *pch)
> +{
> + u8 reg8;
> +
> + dm_pci_read_config8(pch, 0xdc, ®8);
> + reg8 &= ~(3 << 2);
> + reg8 |= (2 << 2); /* Prefetching and Caching Enabled */
> + dm_pci_write_config8(pch, 0xdc, reg8);
> +}
> +
> +static void enable_port80_on_lpc(struct udevice *pch)
> +{
> + /* Enable port 80 POST on LPC */
> + dm_pci_write_config32(pch, PCH_RCBA_BASE, RCB_BASE_ADDRESS | 1);
> + clrbits_le32(RCB_REG(GCS), 4);
> +}
> +
> +/**
> + * lpc_early_init() - set up LPC serial ports and other early things
> + *
> + * @dev: LPC device
> + * @return 0 if OK, -ve on error
> + */
> +int lpc_common_early_init(struct udevice *dev)
> +{
> + struct udevice *pch = dev->parent;
> + struct reg_info {
> + u32 base;
> + u32 size;
> + } values[4], *ptr;
> + int count;
> + int i;
> +
> + count = fdtdec_get_int_array_count(gd->fdt_blob, dev->of_offset,
> + "intel,gen-dec", (u32 *)values,
> + sizeof(values) / sizeof(u32));
> + if (count < 0)
> + return -EINVAL;
> +
> + /* Set COM1/COM2 decode range */
> + dm_pci_write_config16(pch, LPC_IO_DEC, 0x0010);
> +
> + /* Enable PS/2 Keyboard/Mouse, EC areas and COM1 */
> + dm_pci_write_config16(pch, LPC_EN, KBC_LPC_EN | MC_LPC_EN |
> + GAMEL_LPC_EN | COMA_LPC_EN);
> +
> + /* Write all registers but use 0 if we run out of data */
> + count = count * sizeof(u32) / sizeof(values[0]);
> + for (i = 0, ptr = values; i < ARRAY_SIZE(values); i++, ptr++) {
> + u32 reg = 0;
> +
> + if (i < count)
> + reg = ptr->base | PCI_COMMAND_IO | (ptr->size << 16);
> + dm_pci_write_config32(pch, LPC_GENX_DEC(i), reg);
> + }
> +
> + enable_spi_prefetch(pch);
> +
> + /* This is already done in start.S, but let's do it in C */
> + enable_port80_on_lpc(pch);
> +
> + return 0;
> +}
> +
> +int lpc_set_spi_protect(struct udevice *dev, int bios_ctrl, bool protect)
> +{
> + uint8_t bios_cntl;
> +
> + /* Adjust the BIOS write protect and SMM BIOS Write Protect Disable */
> + dm_pci_read_config8(dev, bios_ctrl, &bios_cntl);
> + if (protect) {
> + bios_cntl &= ~BIOS_CTRL_BIOSWE;
> + bios_cntl |= BIT(5);
> + } else {
> + bios_cntl |= BIOS_CTRL_BIOSWE;
> + bios_cntl &= ~BIT(5);
> + }
> + dm_pci_write_config8(dev, bios_ctrl, bios_cntl);
> +
> + return 0;
> +}
> diff --git a/arch/x86/cpu/ivybridge/bd82x6x.c
> b/arch/x86/cpu/ivybridge/bd82x6x.c
> index 55057e0..4c039ac 100644
> --- a/arch/x86/cpu/ivybridge/bd82x6x.c
> +++ b/arch/x86/cpu/ivybridge/bd82x6x.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -188,20 +189,7 @@ static int bd82x6x_pch_get_spi_base(struct udevice *dev,
> ulong *sbasep)
>
> static int bd82x6x_set_spi_protect(struct udevice *dev, bool protect)
> {
> - uint8_t bios_cntl;
> -
> - /* Adjust the BIOS write protect and SMM BIOS Write Protect Disable */
> - dm_pci_read_config8(d
Re: [U-Boot] [PATCH 12/69] malloc_simple: Add a little more debugging
On Fri, Mar 11, 2016 at 12:18 PM, Bin Meng wrote: > On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: >> Output the pointer returned by each call to malloc(). This can be useful >> when debugging memory problems. >> >> Signed-off-by: Simon Glass >> --- >> >> common/malloc_simple.c | 7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> > > Reviewed-by: Bin Meng applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/69] x86: cpu: Make the vendor table const
On Fri, Mar 11, 2016 at 12:32 PM, Bin Meng wrote: > On Mon, Mar 7, 2016 at 10:27 AM, Simon Glass wrote: >> This does not need to be modified at run-time, so make it const. >> >> Signed-off-by: Simon Glass >> --- >> >> arch/x86/cpu/cpu.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> > > Reviewed-by: Bin Meng applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/69] x86: Add some more common MSR indexes
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote: > Many of the model-specific indexes are common to several Intel CPUs. Add > some more common ones, and remove them from the ivybridge-specific header > file. > > Signed-off-by: Simon Glass > --- > > arch/x86/cpu/ivybridge/model_206ax.c | 5 +-- > arch/x86/include/asm/arch-ivybridge/model_206ax.h | 17 -- > arch/x86/include/asm/msr-index.h | 41 > ++- > 3 files changed, 43 insertions(+), 20 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 20/69] x86: Move common LPC code to its own place
On Fri, Mar 11, 2016 at 1:05 PM, Bin Meng wrote: > Hi Simon, > > On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote: >> Some of the LPC code is common to several Intel LPC devices. Move it into a >> common location. >> >> Signed-off-by: Simon Glass >> --- >> >> arch/x86/cpu/intel_common/Makefile| 1 + >> arch/x86/cpu/intel_common/lpc_common.c| 102 >> ++ Forget to mention: can we just use "lpc.c" as the name as "_common" is already in the directory name? >> arch/x86/cpu/ivybridge/bd82x6x.c | 16 + >> arch/x86/cpu/ivybridge/lpc.c | 73 ++--- >> arch/x86/include/asm/arch-ivybridge/pch.h | 2 - >> arch/x86/include/asm/lpc_common.h | 59 + >> 6 files changed, 168 insertions(+), 85 deletions(-) >> create mode 100644 arch/x86/cpu/intel_common/lpc_common.c >> create mode 100644 arch/x86/include/asm/lpc_common.h >> Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 22/69] x86: Move common CPU code to its own place
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Some of the Intel CPU code is common to several Intel CPUs. Move it into a
> common location along with required declarations.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/intel_common/Makefile| 1 +
> arch/x86/cpu/intel_common/cpu_common.c| 111
> ++
> arch/x86/cpu/ivybridge/cpu.c | 82 ++
> arch/x86/include/asm/arch-ivybridge/pch.h | 2 -
> arch/x86/include/asm/cpu_common.h | 35 ++
> arch/x86/include/asm/intel_regs.h | 9 +++
> 6 files changed, 162 insertions(+), 78 deletions(-)
> create mode 100644 arch/x86/cpu/intel_common/cpu_common.c
> create mode 100644 arch/x86/include/asm/cpu_common.h
>
> diff --git a/arch/x86/cpu/intel_common/Makefile
> b/arch/x86/cpu/intel_common/Makefile
> index 36c150d..e9a2b29 100644
> --- a/arch/x86/cpu/intel_common/Makefile
> +++ b/arch/x86/cpu/intel_common/Makefile
> @@ -5,6 +5,7 @@
> #
>
> obj-$(CONFIG_HAVE_MRC) += car.o
> +obj-y += cpu_common.o
Remove _common in the name?
> obj-y += lpc_common.o
> ifndef CONFIG_TARGET_EFI
> obj-y += microcode_intel.o
> diff --git a/arch/x86/cpu/intel_common/cpu_common.c
> b/arch/x86/cpu/intel_common/cpu_common.c
> new file mode 100644
> index 000..1210943
> --- /dev/null
> +++ b/arch/x86/cpu/intel_common/cpu_common.c
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (c) 2016 Google, Inc
> + *
> + * SPDX-License-Identifier:GPL-2.0
nits: GPL-2.0+?
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static int report_bist_failure(void)
> +{
> + if (gd->arch.bist != 0) {
> + post_code(POST_BIST_FAILURE);
> + printf("BIST failed: %08x\n", gd->arch.bist);
> + return -EFAULT;
> + }
> +
> + return 0;
> +}
> +
> +int cpu_common_init(void)
> +{
> + struct udevice *dev, *lpc;
> + int ret;
> +
> + /* Halt if there was a built in self test failure */
> + ret = report_bist_failure();
> + if (ret)
> + return ret;
> +
> + enable_lapic();
> +
> + ret = microcode_update_intel();
> + if (ret && ret != -EEXIST)
> + return ret;
> +
> + /* Enable upper 128bytes of CMOS */
> + writel(1 << 2, RCB_REG(RC));
> +
> + /* Early chipset init required before RAM init can work */
> + uclass_first_device(UCLASS_NORTHBRIDGE, &dev);
> +
> + ret = uclass_first_device(UCLASS_LPC, &lpc);
> + if (ret)
> + return ret;
> + if (!lpc)
> + return -ENODEV;
> +
> + /* Cause the SATA device to do its early init */
> + uclass_first_device(UCLASS_DISK, &dev);
> +
> + return 0;
> +}
> +
> +int cpu_set_flex_ratio_to_tdp_nominal(void)
> +{
> + msr_t flex_ratio, msr;
> + u8 nominal_ratio;
> +
> + /* Check for Flex Ratio support */
> + flex_ratio = msr_read(MSR_FLEX_RATIO);
> + if (!(flex_ratio.lo & FLEX_RATIO_EN))
> + return -EINVAL;
> +
> + /* Check for >0 configurable TDPs */
> + msr = msr_read(MSR_PLATFORM_INFO);
> + if (((msr.hi >> 1) & 3) == 0)
> + return -EINVAL;
> +
> + /* Use nominal TDP ratio for flex ratio */
> + msr = msr_read(MSR_CONFIG_TDP_NOMINAL);
> + nominal_ratio = msr.lo & 0xff;
> +
> + /* See if flex ratio is already set to nominal TDP ratio */
> + if (((flex_ratio.lo >> 8) & 0xff) == nominal_ratio)
> + return 0;
> +
> + /* Set flex ratio to nominal TDP ratio */
> + flex_ratio.lo &= ~0xff00;
> + flex_ratio.lo |= nominal_ratio << 8;
> + flex_ratio.lo |= FLEX_RATIO_LOCK;
> + msr_write(MSR_FLEX_RATIO, flex_ratio);
> +
> + /* Set flex ratio in soft reset data register bits 11:6 */
> + clrsetbits_le32(RCB_REG(SOFT_RESET_DATA), 0x3f << 6,
> + (nominal_ratio & 0x3f) << 6);
> +
> + debug("CPU: Soft reset to set up flex ratio\n");
> +
> + /* Set soft reset control to use register value */
> + setbits_le32(RCB_REG(SOFT_RESET_CTRL), 1);
> +
> + /* Issue warm reset, will be "CPU only" due to soft reset data */
> + outb(0x0, PORT_RESET);
> + outb(SYS_RST | RST_CPU, PORT_RESET);
> + cpu_hlt();
> +
> + /* Not reached */
> + return -EINVAL;
> +}
> diff --git a/arch/x86/cpu/ivybridge/cpu.c b/arch/x86/cpu/ivybridge/cpu.c
> index f847a2f..b8234ae 100644
> --- a/arch/x86/cpu/ivybridge/cpu.c
> +++ b/arch/x86/cpu/ivybridge/cpu.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -34,51 +35,11 @@ DECLARE_GLOBAL_DATA_PTR;
>
> static int set_flex_ratio_to_tdp_nominal(void)
> {
> - msr_t flex_ratio, msr;
> - u8 nominal_ratio;
> -
>
Re: [U-Boot] [PATCH 23/69] x86: Rename PORT_RESET to IO_PORT_RESET
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote: > This same name is used in USB. Add a prefix to distinguish it. > > Signed-off-by: Simon Glass > --- > > arch/x86/cpu/cpu.c | 4 ++-- > arch/x86/cpu/intel_common/cpu_common.c | 4 ++-- > arch/x86/include/asm/processor.h | 2 +- > 3 files changed, 5 insertions(+), 5 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 24/69] x86: Move Intel Management Engine code to a common place
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> Some of the Intel ME code is common to several Intel CPUs. Move it into a
> common location. Add a header file for report_platform.c also.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/intel_common/Makefile | 2 +
> .../cpu/{ivybridge => intel_common}/me_status.c| 20 +-
> .../{ivybridge => intel_common}/report_platform.c | 2 +-
> arch/x86/cpu/ivybridge/Makefile| 2 -
> arch/x86/cpu/ivybridge/early_me.c | 31 +-
> arch/x86/cpu/ivybridge/sdram.c | 3 +-
> arch/x86/include/asm/arch-ivybridge/me.h | 333 +-
> arch/x86/include/asm/arch-ivybridge/sandybridge.h | 2 -
> arch/x86/include/asm/me_common.h | 372
> +
> arch/x86/include/asm/report_platform.h | 19 ++
> 10 files changed, 417 insertions(+), 369 deletions(-)
> rename arch/x86/cpu/{ivybridge => intel_common}/me_status.c (93%)
> rename arch/x86/cpu/{ivybridge => intel_common}/report_platform.c (98%)
> create mode 100644 arch/x86/include/asm/me_common.h
> create mode 100644 arch/x86/include/asm/report_platform.h
>
> diff --git a/arch/x86/cpu/intel_common/Makefile
> b/arch/x86/cpu/intel_common/Makefile
> index e9a2b29..50023fe 100644
> --- a/arch/x86/cpu/intel_common/Makefile
> +++ b/arch/x86/cpu/intel_common/Makefile
> @@ -7,6 +7,8 @@
> obj-$(CONFIG_HAVE_MRC) += car.o
> obj-y += cpu_common.o
> obj-y += lpc_common.o
> +obj-$(CONFIG_HAVE_MRC) += me_status.o
> ifndef CONFIG_TARGET_EFI
> obj-y += microcode_intel.o
> endif
> +obj-$(CONFIG_HAVE_MRC) += report_platform.o
> diff --git a/arch/x86/cpu/ivybridge/me_status.c
> b/arch/x86/cpu/intel_common/me_status.c
> similarity index 93%
> rename from arch/x86/cpu/ivybridge/me_status.c
> rename to arch/x86/cpu/intel_common/me_status.c
> index 15cf69f..130d219 100644
> --- a/arch/x86/cpu/ivybridge/me_status.c
> +++ b/arch/x86/cpu/intel_common/me_status.c
> @@ -128,7 +128,14 @@ static const char *const me_progress_policy_values[] = {
> [0x10] = "Required VSCC values for flash parts do not match",
> };
>
> -void intel_me_status(struct me_hfs *hfs, struct me_gmes *gmes)
> +
> +/**
> + * _intel_me_status() - Check Intel Management Engine status
> + *
> + * struct hfs: Firmware status
> + * struct gmes:Management engine status
> + */
> +static void _intel_me_status(struct me_hfs *hfs, struct me_gmes *gmes)
> {
> /* Check Current States */
> debug("ME: FW Partition Table : %s\n",
> @@ -193,3 +200,14 @@ void intel_me_status(struct me_hfs *hfs, struct me_gmes
> *gmes)
> }
> debug("\n");
> }
> +
> +void intel_me_status(struct udevice *me_dev)
> +{
> + struct me_hfs hfs;
> + struct me_gmes gmes;
> +
> + pci_read_dword_ptr(me_dev, &hfs, PCI_ME_HFS);
> + pci_read_dword_ptr(me_dev, &gmes, PCI_ME_GMES);
The call to pci_read_dword_ptr() looks odd. Why not use the dm_pci_xx
APIs directly?
> +
> + _intel_me_status(&hfs, &gmes);
> +}
> diff --git a/arch/x86/cpu/ivybridge/report_platform.c
> b/arch/x86/cpu/intel_common/report_platform.c
> similarity index 98%
> rename from arch/x86/cpu/ivybridge/report_platform.c
> rename to arch/x86/cpu/intel_common/report_platform.c
> index c78322a..05e1cf9 100644
> --- a/arch/x86/cpu/ivybridge/report_platform.c
> +++ b/arch/x86/cpu/intel_common/report_platform.c
> @@ -9,8 +9,8 @@
> #include
> #include
> #include
> +#include
> #include
> -#include
>
> static void report_cpu_info(void)
> {
> diff --git a/arch/x86/cpu/ivybridge/Makefile b/arch/x86/cpu/ivybridge/Makefile
> index 78006f1..9cdb07b 100644
> --- a/arch/x86/cpu/ivybridge/Makefile
> +++ b/arch/x86/cpu/ivybridge/Makefile
> @@ -11,10 +11,8 @@ obj-y += cpu.o
> obj-y += early_me.o
> obj-y += gma.o
> obj-y += lpc.o
> -obj-y += me_status.o
> obj-y += model_206ax.o
> obj-y += northbridge.o
> -obj-y += report_platform.o
> obj-y += sata.o
> obj-y += sdram.o
> endif
> diff --git a/arch/x86/cpu/ivybridge/early_me.c
> b/arch/x86/cpu/ivybridge/early_me.c
> index b1df77d..cda96ab 100644
> --- a/arch/x86/cpu/ivybridge/early_me.c
> +++ b/arch/x86/cpu/ivybridge/early_me.c
> @@ -27,35 +27,6 @@ static const char *const me_ack_values[] = {
> [ME_HFS_ACK_CONTINUE] = "Continue to boot"
> };
>
> -static inline void pci_read_dword_ptr(struct udevice *me_dev, void *ptr,
> - int offset)
> -{
> - u32 dword;
> -
> - dm_pci_read_config32(me_dev, offset, &dword);
> - memcpy(ptr, &dword, sizeof(dword));
> -}
> -
> -static inline void pci_write_dword_ptr(struct udevice *me_dev, void *ptr,
> - int offset)
> -{
> - u32 dword = 0;
> -
> - memcpy(&dword, ptr, sizeof(dword));
> - dm_pci_write_config32(me_dev, offset, dword);
> -}
> -
> -void intel_early_me_status(struct udevice *me_dev)
> -{
> -
Re: [U-Boot] [PATCH 25/69] x86: ivybridge: Drop sandybridge_early_init()
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote: > This function was removed in the previous clean-up. Drop it from the header > file also. > > Signed-off-by: Simon Glass > --- > > arch/x86/include/asm/arch-ivybridge/sandybridge.h | 2 -- > 1 file changed, 2 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 21/69] x86: Add some more common MSR indexes
On Fri, Mar 11, 2016 at 1:15 PM, Bin Meng wrote: > On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote: >> Many of the model-specific indexes are common to several Intel CPUs. Add >> some more common ones, and remove them from the ivybridge-specific header >> file. >> >> Signed-off-by: Simon Glass >> --- >> >> arch/x86/cpu/ivybridge/model_206ax.c | 5 +-- >> arch/x86/include/asm/arch-ivybridge/model_206ax.h | 17 -- >> arch/x86/include/asm/msr-index.h | 41 >> ++- >> 3 files changed, 43 insertions(+), 20 deletions(-) >> > > Reviewed-by: Bin Meng applied to u-boot-x86/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 26/69] x86: Move common PCH code into a common place
Hi Simon,
On Mon, Mar 7, 2016 at 10:28 AM, Simon Glass wrote:
> The SATA indexed register write functions are common to several Intel PCHs.
> Move this into a common location.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/x86/cpu/intel_common/Makefile| 1 +
> arch/x86/cpu/intel_common/pch_common.c| 25 ++
> arch/x86/cpu/ivybridge/cpu.c | 1 +
> arch/x86/cpu/ivybridge/sata.c | 47 +-
> arch/x86/include/asm/arch-ivybridge/pch.h | 53 -
> arch/x86/include/asm/pch_common.h | 56
> +++
> board/intel/cougarcanyon2/cougarcanyon2.c | 1 +
> 7 files changed, 100 insertions(+), 84 deletions(-)
> create mode 100644 arch/x86/cpu/intel_common/pch_common.c
> create mode 100644 arch/x86/include/asm/pch_common.h
>
> diff --git a/arch/x86/cpu/intel_common/Makefile
> b/arch/x86/cpu/intel_common/Makefile
> index 50023fe..066b7b5 100644
> --- a/arch/x86/cpu/intel_common/Makefile
> +++ b/arch/x86/cpu/intel_common/Makefile
> @@ -11,4 +11,5 @@ obj-$(CONFIG_HAVE_MRC) += me_status.o
> ifndef CONFIG_TARGET_EFI
> obj-y += microcode_intel.o
> endif
> +obj-y += pch_common.o
> obj-$(CONFIG_HAVE_MRC) += report_platform.o
> diff --git a/arch/x86/cpu/intel_common/pch_common.c
> b/arch/x86/cpu/intel_common/pch_common.c
> new file mode 100644
> index 000..1f05b44
> --- /dev/null
> +++ b/arch/x86/cpu/intel_common/pch_common.c
> @@ -0,0 +1,25 @@
> +/*
> + * Copyright (c) 2016 Google, Inc
> + *
> + * SPDX-License-Identifier:GPL-2.0
nits: GPL-2.0+?
> + */
> +
> +#include
> +#include
> +#include
> +
> +u32 pch_common_sir_read(struct udevice *dev, int idx)
> +{
> + u32 data;
> +
> + dm_pci_write_config32(dev, SATA_SIRI, idx);
> + dm_pci_read_config32(dev, SATA_SIRD, &data);
> +
> + return data;
> +}
> +
> +void pch_common_sir_write(struct udevice *dev, int idx, u32 value)
> +{
> + dm_pci_write_config32(dev, SATA_SIRI, idx);
> + dm_pci_write_config32(dev, SATA_SIRD, value);
> +}
> diff --git a/arch/x86/cpu/ivybridge/cpu.c b/arch/x86/cpu/ivybridge/cpu.c
> index b8234ae..78fa73a 100644
> --- a/arch/x86/cpu/ivybridge/cpu.c
> +++ b/arch/x86/cpu/ivybridge/cpu.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/arch/x86/cpu/ivybridge/sata.c b/arch/x86/cpu/ivybridge/sata.c
> index a59d9ed..c2dbab8 100644
> --- a/arch/x86/cpu/ivybridge/sata.c
> +++ b/arch/x86/cpu/ivybridge/sata.c
> @@ -9,28 +9,13 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -static inline u32 sir_read(struct udevice *dev, int idx)
> -{
> - u32 data;
> -
> - dm_pci_write_config32(dev, SATA_SIRI, idx);
> - dm_pci_read_config32(dev, SATA_SIRD, &data);
> -
> - return data;
> -}
> -
> -static inline void sir_write(struct udevice *dev, int idx, u32 value)
> -{
> - dm_pci_write_config32(dev, SATA_SIRI, idx);
> - dm_pci_write_config32(dev, SATA_SIRD, value);
> -}
> -
> static void common_sata_init(struct udevice *dev, unsigned int port_map)
> {
> u32 reg32;
> @@ -177,27 +162,27 @@ static void bd82x6x_sata_init(struct udevice *dev,
> struct udevice *pch)
> pch_iobp_update(pch, SATA_IOBP_SP1G3IR, 0, port_tx);
>
> /* Additional Programming Requirements */
> - sir_write(dev, 0x04, 0x1600);
> - sir_write(dev, 0x28, 0xa033);
> - reg32 = sir_read(dev, 0x54);
> + pch_common_sir_write(dev, 0x04, 0x1600);
> + pch_common_sir_write(dev, 0x28, 0xa033);
> + reg32 = pch_common_sir_read(dev, 0x54);
> reg32 &= 0xff00;
> reg32 |= 0xaa;
> - sir_write(dev, 0x54, reg32);
> - sir_write(dev, 0x64, 0x8484);
> - reg32 = sir_read(dev, 0x68);
> + pch_common_sir_write(dev, 0x54, reg32);
> + pch_common_sir_write(dev, 0x64, 0x8484);
> + reg32 = pch_common_sir_read(dev, 0x68);
> reg32 &= 0x;
> reg32 |= 0x;
> - sir_write(dev, 0x68, reg32);
> - reg32 = sir_read(dev, 0x78);
> + pch_common_sir_write(dev, 0x68, reg32);
> + reg32 = pch_common_sir_read(dev, 0x78);
> reg32 &= 0x;
> reg32 |= 0x;
> - sir_write(dev, 0x78, reg32);
> - sir_write(dev, 0x84, 0x001c7000);
> - sir_write(dev, 0x88, 0x88338822);
> - sir_write(dev, 0xa0, 0x001c7000);
> - sir_write(dev, 0xc4, 0x0c0c0c0c);
> - sir_write(dev, 0xc8, 0x0c0c0c0c);
> - sir_write(dev, 0xd4, 0x1000);
> + pch_common_sir_write(dev, 0x78, reg32);
> + pch_common_sir_write(dev, 0x84, 0x001c7000);
> + pch_common_sir_write(dev, 0x88, 0x88338822);
> + pch_common_sir_write(dev, 0xa0, 0x001c7000);
> + pch_common_sir_write(dev, 0xc4, 0x0c0c0c0c);
> + pch_common_sir_write(dev, 0xc8, 0x0c0c0c0c);
