Re: [U-Boot] [PATCH 1/3] samsung: board: support eMMC reset using DT
On Fri, 2015-01-09 at 16:42 +0900, Joonyoung Shim wrote: > Hi, > > On 01/09/2015 01:21 PM, Jaehoon Chung wrote: > > On 01/09/2015 08:23 AM, Sjoerd Simons wrote: > >> On Thu, 2015-01-08 at 14:44 +0900, Joonyoung Shim wrote: > >>> Some exynos boards require special handling of SD4_nRESET_OUT line for > >>> eMMC memory to perform complete reboot e.g. Odroid X2/U3/XU3 boards. > >>> > >>> This will support eMMC reset using DT from reset_misc of samsung common > >>> board file and each board files can support eMMC reset on non DT case. > >>> > >>> Signed-off-by: Joonyoung Shim > >> > >>> diff --git a/doc/device-tree-bindings/exynos/emmc-reset.txt > >>> b/doc/device-tree-bindings/exynos/emmc-reset.txt > >>> new file mode 100644 > >>> index 000..e48e508 > >>> --- /dev/null > >>> +++ b/doc/device-tree-bindings/exynos/emmc-reset.txt > >>> @@ -0,0 +1,15 @@ > >>> +* Samsung eMMC reset > >>> + > >>> +Some exynos boards require special handling of SD4_nRESET_OUT line for > >>> eMMC > >>> +memory to perform complete reboot. > >> > >> Nitpick, on XU3 the line you apparently need to twiddle is > >> SD0_nRESET_OUT. > >> > > Then, i think it's better to omit "SD4_". > > >> Is this type of usage of this pin specific to the Odroid Exynos boards > >> or potentially on more boards? (Sorry for the simple questions, but my > >> exynos documentation just says the line exists not what its intended > >> usage is). > > > > In case of Exynos4, eMMC can be used with sdhci controller or dw-mmc > > controller. > > So Pin name should be used to SD0 or SD4. > > > > But Exynos5 is only supported the dw-mmc controller. > > (So eMMC is used pin-name as "SD0".) > > > > I can find only "SD_4_nRESET_OUT" from exynos4412 user manual and only > "SD_0__nRESET_OUT" from exynos5422 user manual. > > > Best Regards, > > Jaehoon Chung > >> > >> Fwiw, I did a quick check in the linux code and it doesn't seem to be > >> using those pins for currently for any boards. However my X2 does > >> successfully reset/reboot in u-boot and linux, so it seems optional > >> there. The XU3 does fail to reset itself, so it seems required for that > >> board. > >> > > I checked upstream u-boot and hardkernel u-boot and i found codes to > reset eMMC using gpio. > > upstream u-boot: reset_misc() of board/samsung/odroid/odroid.c > hardkernel u-boot: reset_cpu() of arch/arm/cpu/armv7/exynos/reset.c Yeah u-boot does it, but linux upstream kernel does not. Hence wondering about the requirements. -- Sjoerd Simons Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] samsung: board: support eMMC reset using DT
On 09/01/15 16:31, Joonyoung Shim wrote:
> +Cc Jaehoon,
>
> On 01/09/2015 03:18 AM, Simon Glass wrote:
>> Hi Joonyoung,
>>
>> On 7 January 2015 at 22:44, Joonyoung Shim wrote:
>>> Some exynos boards require special handling of SD4_nRESET_OUT line for
>>> eMMC memory to perform complete reboot e.g. Odroid X2/U3/XU3 boards.
>>>
>>> This will support eMMC reset using DT from reset_misc of samsung common
>>> board file and each board files can support eMMC reset on non DT case.
>>>
>>> Signed-off-by: Joonyoung Shim
>>> ---
>>> board/samsung/common/board.c | 27
>>> ++
>>> board/samsung/odroid/odroid.c | 2 +-
>>> doc/device-tree-bindings/exynos/emmc-reset.txt | 15 ++
>>> 3 files changed, 43 insertions(+), 1 deletion(-)
>>> create mode 100644 doc/device-tree-bindings/exynos/emmc-reset.txt
>>>
>>> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
>>> index c04ab3c..3218463 100644
>>> --- a/board/samsung/common/board.c
>>> +++ b/board/samsung/common/board.c
>>> @@ -40,6 +40,8 @@ __weak int exynos_power_init(void)
>>> return 0;
>>> }
>>>
>>> +__weak void exynos_reset_misc(void) {}
>>> +
>>> #if defined CONFIG_EXYNOS_TMU
>>> /* Boot Time Thermal Analysis for SoC temperature threshold breach */
>>> static void boot_temp_check(void)
>>> @@ -400,3 +402,28 @@ int misc_init_r(void)
>>> return 0;
>>> }
>>> #endif
>>> +
>>> +void reset_misc(void)
>>> +{
>>> +#ifdef CONFIG_OF_CONTROL
>>
>> I think all Samsung boards have this defined, so this #ifdef can be removed.
>>
>
> OK, if it is true, we can remove this and i will not to support non DT case.
It's OK.
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] samsung: board: support eMMC reset using DT
Hi, On 01/09/2015 01:21 PM, Jaehoon Chung wrote: > On 01/09/2015 08:23 AM, Sjoerd Simons wrote: >> On Thu, 2015-01-08 at 14:44 +0900, Joonyoung Shim wrote: >>> Some exynos boards require special handling of SD4_nRESET_OUT line for >>> eMMC memory to perform complete reboot e.g. Odroid X2/U3/XU3 boards. >>> >>> This will support eMMC reset using DT from reset_misc of samsung common >>> board file and each board files can support eMMC reset on non DT case. >>> >>> Signed-off-by: Joonyoung Shim >> >>> diff --git a/doc/device-tree-bindings/exynos/emmc-reset.txt >>> b/doc/device-tree-bindings/exynos/emmc-reset.txt >>> new file mode 100644 >>> index 000..e48e508 >>> --- /dev/null >>> +++ b/doc/device-tree-bindings/exynos/emmc-reset.txt >>> @@ -0,0 +1,15 @@ >>> +* Samsung eMMC reset >>> + >>> +Some exynos boards require special handling of SD4_nRESET_OUT line for eMMC >>> +memory to perform complete reboot. >> >> Nitpick, on XU3 the line you apparently need to twiddle is >> SD0_nRESET_OUT. >> Then, i think it's better to omit "SD4_". >> Is this type of usage of this pin specific to the Odroid Exynos boards >> or potentially on more boards? (Sorry for the simple questions, but my >> exynos documentation just says the line exists not what its intended >> usage is). > > In case of Exynos4, eMMC can be used with sdhci controller or dw-mmc > controller. > So Pin name should be used to SD0 or SD4. > > But Exynos5 is only supported the dw-mmc controller. > (So eMMC is used pin-name as "SD0".) > I can find only "SD_4_nRESET_OUT" from exynos4412 user manual and only "SD_0__nRESET_OUT" from exynos5422 user manual. > Best Regards, > Jaehoon Chung >> >> Fwiw, I did a quick check in the linux code and it doesn't seem to be >> using those pins for currently for any boards. However my X2 does >> successfully reset/reboot in u-boot and linux, so it seems optional >> there. The XU3 does fail to reset itself, so it seems required for that >> board. >> I checked upstream u-boot and hardkernel u-boot and i found codes to reset eMMC using gpio. upstream u-boot: reset_misc() of board/samsung/odroid/odroid.c hardkernel u-boot: reset_cpu() of arch/arm/cpu/armv7/exynos/reset.c Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Odroid: Add eMMC-reset node on DT
+Cc Jaehoon,
On 01/09/2015 03:20 AM, Simon Glass wrote:
> Hi,
>
> On 7 January 2015 at 22:44, Joonyoung Shim wrote:
>> This needs for special handling of SD4_nRESET_OUT line for eMMC memory
>> to perform complete reboot on Odroid X2/U3 boards.
>>
>> Signed-off-by: Joonyoung Shim
>> ---
>> arch/arm/dts/exynos4412-odroid.dts | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/dts/exynos4412-odroid.dts
>> b/arch/arm/dts/exynos4412-odroid.dts
>> index ecb3e23..519a7dd 100644
>> --- a/arch/arm/dts/exynos4412-odroid.dts
>> +++ b/arch/arm/dts/exynos4412-odroid.dts
>> @@ -90,4 +90,9 @@
>> reg = <0x125B 0x100>;
>> };
>> };
>> +
>> + emmc-reset {
>> + compatible = "samsung,emmc-reset";
>> + reset-gpio = <&gpk1 2 0>;
>> + };
>> };
>
> Shouldn't this go in the relevant sdhci node instead of its own node?
>
Jaehoon, is it reasonable?
Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] samsung: board: support eMMC reset using DT
+Cc Jaehoon,
On 01/09/2015 03:18 AM, Simon Glass wrote:
> Hi Joonyoung,
>
> On 7 January 2015 at 22:44, Joonyoung Shim wrote:
>> Some exynos boards require special handling of SD4_nRESET_OUT line for
>> eMMC memory to perform complete reboot e.g. Odroid X2/U3/XU3 boards.
>>
>> This will support eMMC reset using DT from reset_misc of samsung common
>> board file and each board files can support eMMC reset on non DT case.
>>
>> Signed-off-by: Joonyoung Shim
>> ---
>> board/samsung/common/board.c | 27
>> ++
>> board/samsung/odroid/odroid.c | 2 +-
>> doc/device-tree-bindings/exynos/emmc-reset.txt | 15 ++
>> 3 files changed, 43 insertions(+), 1 deletion(-)
>> create mode 100644 doc/device-tree-bindings/exynos/emmc-reset.txt
>>
>> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
>> index c04ab3c..3218463 100644
>> --- a/board/samsung/common/board.c
>> +++ b/board/samsung/common/board.c
>> @@ -40,6 +40,8 @@ __weak int exynos_power_init(void)
>> return 0;
>> }
>>
>> +__weak void exynos_reset_misc(void) {}
>> +
>> #if defined CONFIG_EXYNOS_TMU
>> /* Boot Time Thermal Analysis for SoC temperature threshold breach */
>> static void boot_temp_check(void)
>> @@ -400,3 +402,28 @@ int misc_init_r(void)
>> return 0;
>> }
>> #endif
>> +
>> +void reset_misc(void)
>> +{
>> +#ifdef CONFIG_OF_CONTROL
>
> I think all Samsung boards have this defined, so this #ifdef can be removed.
>
OK, if it is true, we can remove this and i will not to support non DT case.
>> + struct gpio_desc gpio = {};
>> + int node;
>> +
>> + node = fdt_node_offset_by_compatible(gd->fdt_blob, 0,
>> + "samsung,emmc-reset");
>> + if (node < 0)
>> + return;
>> +
>> + gpio_request_by_name_nodev(gd->fdt_blob, node, "reset-gpio", 0,
>> &gpio,
>> + GPIOD_IS_OUT);
>> +
>> + if (dm_gpio_is_valid(&gpio)) {
>> + /* Reset eMMC*/
>> + dm_gpio_set_value(&gpio, 0);
>> + mdelay(10);
>
> That's a very long reset! Is that what it needs?
>
Jaehoon, is there any guide about wait time of reset at eMMC spec?
Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: gadget: pxa25x_udc: fix use-before-initialized bug
On Thursday, January 08, 2015 at 07:19:35 PM, Nable wrote: Hi! > > You can use [PATCH RESEND], which is probably much clearer in expressing > > the intent. You might add a short note just before the diffstat saying > > that you only updated the SoB line and author to match the real deal, > > but didn't change the patch contents. > > I've edited my patch and it's still applies on to top HEAD of master > branch, so I've sent fixed version to mailing list. Thanks! > Thank you for > mentioning this idea of commentaries before diffstat output, I've never > heard about it. It's mostly useful to save reviewers the time figuring out what changed in the patch and such message never propagates into the applied patch in the tree :) > > You can read [1] for the finer points of patch submission process, but > > TL;DR > > it's pretty much the same as Linux ;-) > > Sounds like a nice joke! In fact, I'm doing my first steps in open-source > software, so sending patches to Linux is something like a far dream. > But if I reach that stage someday, then I'll be able to say that it's > "pretty much the same as for U-Boot". Heh, everyone's been there at some point. Good luck and have fun :) > > [1] http://www.denx.de/wiki/U-Boot/Patches#General_Patch_Submission_Rules > > I've studied [1] yesterday, and looked through it again today, > so I hope that I'm doing everything in a right way this time. Yeah, no worries. You'll quickly get the hang of it and someone will remind you in case you screw up bigtime anyway ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/18] exynos5: config: prepare for dm i2c support
Hello Przemyslaw Marczak, Am 08.01.2015 12:33, schrieb Przemyslaw Marczak: This commit allows for test i2c drivers with new i2c api on Exynos5xxx based boards. The S3C24X0 I2C driver supports driver model I2C api, but i2c peripherials drivers on exynos5 boards doesn't. So this commit allows for test ported driver before switch the Exynos5 boards to DM I2C at all. Hmm... so this is just a patch for test purposes not for mainline? Signed-off-by: Przemyslaw Marczak Cc: Akshay Saraswat Cc: Simon Glass Cc: Minkyu Kang --- include/configs/exynos5-common.h | 29 ++--- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index ad63f3c..b7af8a5 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -54,13 +54,6 @@ #define CONFIG_CMD_DTT #define CONFIG_TMU_CMD_DTT -/* TPM */ -#define CONFIG_TPM -#define CONFIG_CMD_TPM -#define CONFIG_TPM_TIS_I2C -#define CONFIG_TPM_TIS_I2C_BUS_NUMBER 3 -#define CONFIG_TPM_TIS_I2C_SLAVE_ADDR 0x20 - /* MMC SPL */ #define COPY_BL2_FNPTR_ADDR 0x02020030 #define CONFIG_SUPPORT_EMMC_BOOT @@ -126,15 +119,29 @@ #define SPI_FLASH_UBOOT_POS (CONFIG_SEC_FW_SIZE + CONFIG_BL1_SIZE) /* I2C */ -#define CONFIG_SYS_I2C_INIT_BOARD -#define CONFIG_SYS_I2C +#if 0 /* For test */ +#define CONFIG_DM_I2C +#endif Hmm.. no, please no dead code in mainline ... maybe you enable "CONFIG_DM_I2C" if "CONFIG_DM" is set? bye, Heiko #define CONFIG_CMD_I2C -#define CONFIG_SYS_I2C_S3C24X0_SPEED 10 /* 100 Kbps */ #define CONFIG_SYS_I2C_S3C24X0 -#define CONFIG_I2C_MULTI_BUS +#define CONFIG_SYS_I2C_S3C24X0_SPEED 10 /* 100 Kbps */ #define CONFIG_SYS_I2C_S3C24X0_SLAVE0x0 +#ifndef CONFIG_DM_I2C +#define CONFIG_SYS_I2C_INIT_BOARD +#define CONFIG_SYS_I2C +#define CONFIG_I2C_MULTI_BUS +#endif /* ifndef CONFIG_DM_I2C */ #define CONFIG_I2C_EDID +/* TPM */ +#ifndef CONFIG_DM_I2C +#define CONFIG_TPM +#define CONFIG_CMD_TPM +#define CONFIG_TPM_TIS_I2C +#define CONFIG_TPM_TIS_I2C_BUS_NUMBER 3 +#define CONFIG_TPM_TIS_I2C_SLAVE_ADDR 0x20 +#endif + /* SPI */ #ifdef CONFIG_SPI_FLASH #define CONFIG_EXYNOS_SPI -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/18] dm: i2c: s3c24x0: adjust to dm-i2c api
Hello Przemyslaw Marczak,
just some nitpick ...
Am 08.01.2015 12:33, schrieb Przemyslaw Marczak:
This commit adjusts the s3c24x0 driver to new i2c api
based on driver-model. The driver supports standard
and high-speed i2c as previous.
Tested on Trats2 and Arndale (also with HS).
Signed-off-by: Przemyslaw Marczak
Cc: Simon Glass
Cc: Heiko Schocher
Cc: Minkyu Kang
---
drivers/i2c/s3c24x0_i2c.c | 254 --
1 file changed, 222 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
index fd328f0..c21d479 100644
--- a/drivers/i2c/s3c24x0_i2c.c
+++ b/drivers/i2c/s3c24x0_i2c.c
@@ -9,8 +9,9 @@
* as they seem to have the same I2C controller inside.
* The different address mapping is handled by the s3c24xx.h files below.
*/
-
#include
+#include
+#include
#include
#if (defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
#include
@@ -121,13 +122,23 @@
#define CONFIG_MAX_I2C_NUM 1
#endif
+DECLARE_GLOBAL_DATA_PTR;
+
/*
* For SPL boot some boards need i2c before SDRAM is initialised so force
* variables to live in SRAM
*/
+#ifdef CONFIG_SYS_I2C
static struct s3c24x0_i2c_bus i2c_bus[CONFIG_MAX_I2C_NUM]
__attribute__((section(".data")));
+#endif
+enum exynos_i2c_type {
+ EXYNOS_I2C_STD,
+ EXYNOS_I2C_HS,
+};
+
+#ifdef CONFIG_SYS_I2C
/**
* Get a pointer to the given bus index
*
@@ -147,6 +158,7 @@ static struct s3c24x0_i2c_bus *get_bus(unsigned int bus_idx)
debug("Undefined bus: %d\n", bus_idx);
return NULL;
}
+#endif
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
static int GetI2CSDA(void)
@@ -251,6 +263,7 @@ static void ReadWriteByte(struct s3c24x0_i2c *i2c)
writel(readl(&i2c->iiccon) & ~I2CCON_IRPND, &i2c->iiccon);
}
+#ifdef CONFIG_SYS_I2C
static struct s3c24x0_i2c *get_base_i2c(int bus)
{
#ifdef CONFIG_EXYNOS4
@@ -267,6 +280,7 @@ static struct s3c24x0_i2c *get_base_i2c(int bus)
return s3c24x0_get_base_i2c();
#endif
}
+#endif
static void i2c_ch_init(struct s3c24x0_i2c *i2c, int speed, int slaveadd)
{
@@ -398,18 +412,20 @@ static void exynos5_i2c_reset(struct s3c24x0_i2c_bus
*i2c_bus)
hsi2c_ch_init(i2c_bus);
}
+#ifdef CONFIG_SYS_I2C
static void s3c24x0_i2c_init(struct i2c_adapter *adap, int speed, int
slaveadd)
{
struct s3c24x0_i2c *i2c;
struct s3c24x0_i2c_bus *bus;
-
#if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
struct s3c24x0_gpio *gpio = s3c24x0_get_base_gpio();
#endif
ulong start_time = get_timer(0);
- /* By default i2c channel 0 is the current bus */
i2c = get_base_i2c(adap->hwadapnr);
+ bus = &i2c_bus[adap->hwadapnr];
+ if (!bus)
+ return;
/*
* In case the previous transfer is still going, wait to give it a
@@ -470,12 +486,13 @@ static void s3c24x0_i2c_init(struct i2c_adapter *adap,
int speed, int slaveadd)
#endif
}
#endif /* #if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5) */
+
i2c_ch_init(i2c, speed, slaveadd);
- bus = &i2c_bus[adap->hwadapnr];
bus->active = true;
bus->regs = i2c;
}
+#endif /* CONFIG_SYS_I2C */
/*
* Poll the appropriate bit of the fifo status register until the interface is
@@ -545,7 +562,6 @@ static int hsi2c_prepare_transaction(struct exynos5_hsi2c
*i2c,
bool issue_stop)
{
u32 conf;
-
why do you delete this empty line?
conf = len | HSI2C_MASTER_RUN;
if (issue_stop)
@@ -698,14 +714,24 @@ static int hsi2c_read(struct exynos5_hsi2c *i2c,
return rv;
}
+#ifdef CONFIG_SYS_I2C
static unsigned int s3c24x0_i2c_set_bus_speed(struct i2c_adapter *adap,
- unsigned int speed)
+ unsigned int speed)
+#else
+static int s3c24x0_i2c_set_bus_speed(struct udevice *dev, unsigned int speed)
+#endif
{
struct s3c24x0_i2c_bus *i2c_bus;
-
here too ...
+#ifdef CONFIG_SYS_I2C
i2c_bus = get_bus(adap->hwadapnr);
+#else
+ if (!dev)
+ return -ENODEV;
+
+ i2c_bus = dev_get_priv(dev);
+#endif
if (!i2c_bus)
- return -1;
+ return -ENODEV;
i2c_bus->clock_frequency = speed;
@@ -715,23 +741,12 @@ static unsigned int s3c24x0_i2c_set_bus_speed(struct
i2c_adapter *adap,
hsi2c_ch_init(i2c_bus);
} else {
i2c_ch_init(i2c_bus->regs, i2c_bus->clock_frequency,
- CONFIG_SYS_I2C_S3C24X0_SLAVE);
+ CONFIG_SYS_I2C_S3C24X0_SLAVE);
}
return 0;
}
-#ifdef CONFIG_EXYNOS5
-static void exynos_i2c_init(struct i2c_adapter *adap, int speed, int slaveaddr)
-{
- /* This will override the speed selected in the fdt for that port */
- debug("i2c_init(speed=%u
Re: [U-Boot] [PATCH] i2c:mxc fix array size of i2c_data
Hello Peng Fan,
Am 06.01.2015 07:12, schrieb Peng Fan:
We should not hardcode array size of i2c_data to 3. To CONFIG_FSL_LSCH3,
there are 4 i2c interface, but not 3. So the size of i2c_data array should
be calculated using "ARRAY_SIZE(i2c_bases)".
To avoid compile error, move i2c_bases before sram_data structure which
contains i2c_data array.
Signed-off-by: Peng Fan
---
drivers/i2c/mxc_i2c.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
Acked-by: Heiko Schocher
@Stefano: Would you pick up this patch, or should I?
bye,
Heiko
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 021b2fe..fc5ee35 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -402,17 +402,6 @@ int bus_i2c_write(void *base, uchar chip, uint addr, int
alen,
return ret;
}
-struct i2c_parms {
- void *base;
- void *idle_bus_data;
- int (*idle_bus_fn)(void *p);
-};
-
-struct sram_data {
- unsigned curr_i2c_bus;
- struct i2c_parms i2c_data[3];
-};
-
static void * const i2c_bases[] = {
#if defined(CONFIG_MX25)
(void *)IMX_I2C_BASE,
@@ -439,6 +428,17 @@ static void * const i2c_bases[] = {
#endif
};
+struct i2c_parms {
+ void *base;
+ void *idle_bus_data;
+ int (*idle_bus_fn)(void *p);
+};
+
+struct sram_data {
+ unsigned curr_i2c_bus;
+ struct i2c_parms i2c_data[ARRAY_SIZE(i2c_bases)];
+};
+
void *i2c_get_base(struct i2c_adapter *adap)
{
return i2c_bases[adap->hwadapnr];
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support
Hi Simon, On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass wrote: > Hi Bin, > > On 8 January 2015 at 18:34, Bin Meng wrote: >> Hi Simon, >> >> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass wrote: >>> Hi Bin, >>> >>> On 7 January 2015 at 23:18, Bin Meng wrote: Hi Simon, On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass wrote: > NOT TO APPLY > > This shows how to enable video for the glacier board, as an example of the > emulator working on a VESA-compliant graphics card. > > Signed-off-by: Simon Glass > --- > > include/configs/canyonlands.h | 31 +++ > 1 file changed, 31 insertions(+) > > diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h > index 7a1499d..c55e076 100644 > --- a/include/configs/canyonlands.h > +++ b/include/configs/canyonlands.h > @@ -133,6 +133,9 @@ > #define CONFIG_SYS_NOR_CS 0 /* NOR chip connected to > CSx */ > #define CONFIG_SYS_NAND_CS 3 /* NAND chip connected to > CSx */ > > +#define CONFIG_CONSOLE_MUX > +#define CONFIG_SYS_CONSOLE_IS_IN_ENV > + > /*--- > * FLASH related > > *--*/ > @@ -359,6 +362,15 @@ > "ramdisk_addr=fc20\0" \ > "pciconfighost=1\0" \ > "pcie_mode=RP:RP\0" \ > + "eth1addr=00:01:ec:00:f4:9d\0" \ > + "eth2addr=00:01:ec:00:f4:9e\0" \ > + "eth3addr=00:01:ec:00:f4:9f\0" \ > + "ethact=ppc_4xx_eth0\0" \ > + "ethaddr=00:01:ec:00:f4:9c\0" \ > + "stderr=serial\0" \ > + "stdin=serial\0" \ > + "stdout=serial,vga\0" \ > + "autoload=n\0" \ > "" > #else /* defined(CONFIG_ARCHES) */ > #define CONFIG_EXTRA_ENV_SETTINGS \ > @@ -675,4 +687,23 @@ > } > #endif > > +#define CONFIG_VIDEO > + > +#ifdef CONFIG_VIDEO > +#define CONFIG_BIOSEMU /* x86 bios emulator for vga bios > */ > +#define CONFIG_VIDEO_VESA > +#define VIDEO_IO_OFFSET0xd800 > +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS VIDEO_IO_OFFSET > +#define CONFIG_VIDEO_SW_CURSOR > +#define CONFIG_VIDEO_LOGO > +#define CONFIG_CFB_CONSOLE > +#define CONFIG_SPLASH_SCREEN > +#define CONFIG_VGA_AS_SINGLE_DEVICE > +#define CONFIG_CMD_BMP > +#endif > + > +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE > +#define CONFIG_FRAMEBUFFER_VESA_MODE 0x114 > +#define CONFIG_CMD_TFTPPUT > + > #endif /* __CONFIG_H */ > -- Could you also post the codes that actually run the vga bios on ppc target? I may find another non-x86 board to test. >>> >>> It is all there - I am using the existing support. If you see >>> pci_run_vga_bios() it calls biosemu_run() in the emulation case. >> >> Sorry I mean the complete canyonlands codes which calls >> pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called >> by chromebook_link. And do you think the int15_handler() required by >> the biosemu needs to be common? > > This series is at u-boot-x86/vesa. > > You can see the call from the vesa video driver, vesa_fb.c. Ah, I see. I can have a try on a non-x86 board. > Re int15_handler(), yes I think it should be, but so far I haven't needed it. So what does int15_hander() normally do? I see the vesa_fb.c provided NULL for int15_handler, but the call in arch/x86/cpu/ivybridge/gma.c does not pass NULL. > I think the ROM access code can be made more common, but I left that > task for now. > >> >>> Re your other question I was looking for the VGA enable bit, as I >>> remembered it from years ago. It doesn't seem to be needed for that >>> platforms I have tested. But if it is generally needed we should add >>> it. >> >> Which platform do you use? I doubt the VGA enable bit only affects x86 >> as it opens the A and I/O address decoding which is only >> applicable on x86. > > I'm only using glacier and link so far. I suspect there might be > something wrong as only one of my video cards works fully on glacier - > another once gives a snowy picture. So VGA enable bit is unset on Link as well? That's interesting. When you mentioned two cards, did you insert them simultaneously? I believe only one card will work due to only one card will respond VGA cycles. >> >>> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is >>> called. I wonder if you haven't enabled the ROM BAR? I initially got >>> the same result as you. >> >> Yes, I called pciauto_setup_rom() in my codes. I also verified the >> expansion ROM address r
[U-Boot] [PATCH] arm: ls1021x: Add support for initializing CAAM's stream id
There 4 JRs, 4 RTICs and 8 DECOs, and set them the same stream id
for using the same SMMU3 on LS1021A.
Signed-off-by: Xiubo Li
Signed-off-by: Alison Wang
---
arch/arm/include/asm/arch-ls102xa/config.h | 1 +
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 37 ++
.../include/asm/arch-ls102xa/ls102xa_stream_id.h | 57 ++
board/freescale/common/ls102xa_stream_id.c | 15 ++
board/freescale/ls1021aqds/ls1021aqds.c| 21
board/freescale/ls1021atwr/ls1021atwr.c| 21
6 files changed, 152 insertions(+)
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h
b/arch/arm/include/asm/arch-ls102xa/config.h
index 5e934da..f200bc8 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -36,6 +36,7 @@
#define CONFIG_SYS_LS102XA_USB1_ADDR \
(CONFIG_SYS_IMMR + CONFIG_SYS_LS102XA_USB1_OFFSET)
+#define CONFIG_SYS_FSL_SEC_OFFSET 0x0070
#define CONFIG_SYS_LS102XA_USB1_OFFSET 0x0760
#define CONFIG_SYS_TSEC1_OFFSET0x01d1
#define CONFIG_SYS_TSEC2_OFFSET0x01d5
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 697d4ca..a73ef2e 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -37,6 +37,43 @@
#define DCFG_DCSR_PORCR1 0
+/*
+ * Define default values for some CCSR macros to make header files cleaner*
+ *
+ * To completely disable CCSR relocation in a board header file, define
+ * CONFIG_SYS_CCSR_DO_NOT_RELOCATE. This will force CONFIG_SYS_CCSRBAR_PHYS
+ * to a value that is the same as CONFIG_SYS_CCSRBAR.
+ */
+
+#ifdef CONFIG_SYS_CCSRBAR_PHYS
+#error "Do not define CONFIG_SYS_CCSRBAR_PHYS directly."
+#endif
+
+#ifdef CONFIG_SYS_CCSR_DO_NOT_RELOCATE
+#undef CONFIG_SYS_CCSRBAR_PHYS_HIGH
+#undef CONFIG_SYS_CCSRBAR_PHYS_LOW
+#define CONFIG_SYS_CCSRBAR_PHYS_HIGH 0
+#endif
+
+#ifndef CONFIG_SYS_CCSRBAR
+#define CONFIG_SYS_CCSRBAR CONFIG_SYS_IMMR
+#endif
+
+#ifndef CONFIG_SYS_CCSRBAR_PHYS_HIGH
+#ifdef CONFIG_PHYS_64BIT
+#define CONFIG_SYS_CCSRBAR_PHYS_HIGH 0xf
+#else
+#define CONFIG_SYS_CCSRBAR_PHYS_HIGH 0
+#endif
+#endif
+
+#ifndef CONFIG_SYS_CCSRBAR_PHYS_LOW
+#define CONFIG_SYS_CCSRBAR_PHYS_LOWCONFIG_SYS_IMMR
+#endif
+
+#define CONFIG_SYS_CCSRBAR_PHYS ((CONFIG_SYS_CCSRBAR_PHYS_HIGH * 1ull) << 32 |
\
+CONFIG_SYS_CCSRBAR_PHYS_LOW)
+
struct sys_info {
unsigned long freq_processor[CONFIG_MAX_CPUS];
unsigned long freq_systembus;
diff --git a/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
b/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
index abd70fc..fa571b3 100644
--- a/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
+++ b/arch/arm/include/asm/arch-ls102xa/ls102xa_stream_id.h
@@ -7,11 +7,68 @@
#ifndef __FSL_LS102XA_STREAM_ID_H_
#define __FSL_LS102XA_STREAM_ID_H_
+#include
+
+#define SET_LIODN_ENTRY_1(name, idA, off, compatoff) \
+ { .compat = name, \
+ .id = { idA }, .num_ids = 1, \
+ .reg_offset = off + CONFIG_SYS_IMMR, \
+ .compat_offset = compatoff + CONFIG_SYS_CCSRBAR_PHYS, \
+ }
+
+#define SET_LIODN_ENTRY_2(name, idA, idB, off, compatoff) \
+ { .compat = name, \
+ .id = { idA, idB }, .num_ids = 2, \
+ .reg_offset = off + CONFIG_SYS_IMMR, \
+ .compat_offset = compatoff + CONFIG_SYS_CCSRBAR_PHYS, \
+ }
+
+/*
+ * handle both old and new versioned SEC properties:
+ * "fsl,secX.Y" became "fsl,sec-vX.Y" during development
+ */
+#define SET_SEC_JR_LIODN_ENTRY(jrnum, liodnA, liodnB) \
+ SET_LIODN_ENTRY_2("fsl,sec4.0-job-ring", liodnA, liodnB, \
+ offsetof(ccsr_sec_t, jrliodnr[jrnum].ls) + \
+ CONFIG_SYS_FSL_SEC_OFFSET, \
+ CONFIG_SYS_FSL_SEC_OFFSET + 0x1000 + 0x1000 * jrnum), \
+ SET_LIODN_ENTRY_2("fsl,sec-v4.0-job-ring", liodnA, liodnB,\
+ offsetof(ccsr_sec_t, jrliodnr[jrnum].ls) + \
+ CONFIG_SYS_FSL_SEC_OFFSET, \
+ CONFIG_SYS_FSL_SEC_OFFSET + 0x1000 + 0x1000 * jrnum)
+
+/* This is a bit evil since we treat rtic param as both a string & hex value */
+#define SET_SEC_RTIC_LIODN_ENTRY(rtic, liodnA) \
+ SET_LIODN_ENTRY_1("fsl,sec4.0-rtic-memory", \
+ liodnA, \
+ offsetof(ccsr_sec_t, rticliodnr[0x##rtic-0xa].ls) + \
+ CONFIG_SYS_FSL_SEC_OFFSET, \
+ CONFIG_SYS_FSL_SEC_OFFSET + 0x6100 + 0x20 * (0x##rtic-0xa)), \
+ SET_LIODN_ENTRY_1("fsl,sec-v4.0-rtic-memory", \
+ liodnA, \
+ offsetof(ccsr_sec_t, rticliodnr[0x##rtic-0xa].ls) + \
+ CONFIG_SYS_FSL_SEC_OFFSET, \
+ CONFIG_SYS_FSL_SEC_OFFSET + 0x6100 + 0x20 * (0x##rtic-0xa))
+
+#define SET_SEC_DECO_LIODN_ENTRY(n
[U-Boot] NAND bug fixes for v2015.01
Hi Scott, U-Boot v2015.01 will be released in a few days. (scheduled on January 12) I know you are busy, but can you please check NAND fixes? [1] http://patchwork.ozlabs.org/patch/421803/ [2] http://patchwork.ozlabs.org/patch/424123/ [3] http://patchwork.ozlabs.org/patch/424122/ Especially, [1] and [2] are apparent regressions. I believe they should be fixed by the release. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] samsung: board: support eMMC reset using DT
On 01/09/2015 08:23 AM, Sjoerd Simons wrote:
> On Thu, 2015-01-08 at 14:44 +0900, Joonyoung Shim wrote:
>> Some exynos boards require special handling of SD4_nRESET_OUT line for
>> eMMC memory to perform complete reboot e.g. Odroid X2/U3/XU3 boards.
>>
>> This will support eMMC reset using DT from reset_misc of samsung common
>> board file and each board files can support eMMC reset on non DT case.
>>
>> Signed-off-by: Joonyoung Shim
>
>> diff --git a/doc/device-tree-bindings/exynos/emmc-reset.txt
>> b/doc/device-tree-bindings/exynos/emmc-reset.txt
>> new file mode 100644
>> index 000..e48e508
>> --- /dev/null
>> +++ b/doc/device-tree-bindings/exynos/emmc-reset.txt
>> @@ -0,0 +1,15 @@
>> +* Samsung eMMC reset
>> +
>> +Some exynos boards require special handling of SD4_nRESET_OUT line for eMMC
>> +memory to perform complete reboot.
>
> Nitpick, on XU3 the line you apparently need to twiddle is
> SD0_nRESET_OUT.
>
> Is this type of usage of this pin specific to the Odroid Exynos boards
> or potentially on more boards? (Sorry for the simple questions, but my
> exynos documentation just says the line exists not what its intended
> usage is).
In case of Exynos4, eMMC can be used with sdhci controller or dw-mmc controller.
So Pin name should be used to SD0 or SD4.
But Exynos5 is only supported the dw-mmc controller.
(So eMMC is used pin-name as "SD0".)
Best Regards,
Jaehoon Chung
>
> Fwiw, I did a quick check in the linux code and it doesn't seem to be
> using those pins for currently for any boards. However my X2 does
> successfully reset/reboot in u-boot and linux, so it seems optional
> there. The XU3 does fail to reset itself, so it seems required for that
> board.
>
>> +Required properties:
>> +- compatible: should be "samsung,emmc-reset"
>> +- reset-gpio: gpio chip for eMMC reset.
>> +
>> +Example:
>> +
>> +emmc-reset {
>> +compatible = "samsung,emmc-reset";
>> +reset-gpio = <&gpk1 2 0>;
>> +};
>
>
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support
Hi Bin, On 8 January 2015 at 18:34, Bin Meng wrote: > Hi Simon, > > On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass wrote: >> Hi Bin, >> >> On 7 January 2015 at 23:18, Bin Meng wrote: >>> Hi Simon, >>> >>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass wrote: NOT TO APPLY This shows how to enable video for the glacier board, as an example of the emulator working on a VESA-compliant graphics card. Signed-off-by: Simon Glass --- include/configs/canyonlands.h | 31 +++ 1 file changed, 31 insertions(+) diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h index 7a1499d..c55e076 100644 --- a/include/configs/canyonlands.h +++ b/include/configs/canyonlands.h @@ -133,6 +133,9 @@ #define CONFIG_SYS_NOR_CS 0 /* NOR chip connected to CSx */ #define CONFIG_SYS_NAND_CS 3 /* NAND chip connected to CSx */ +#define CONFIG_CONSOLE_MUX +#define CONFIG_SYS_CONSOLE_IS_IN_ENV + /*--- * FLASH related *--*/ @@ -359,6 +362,15 @@ "ramdisk_addr=fc20\0" \ "pciconfighost=1\0" \ "pcie_mode=RP:RP\0" \ + "eth1addr=00:01:ec:00:f4:9d\0" \ + "eth2addr=00:01:ec:00:f4:9e\0" \ + "eth3addr=00:01:ec:00:f4:9f\0" \ + "ethact=ppc_4xx_eth0\0" \ + "ethaddr=00:01:ec:00:f4:9c\0" \ + "stderr=serial\0" \ + "stdin=serial\0" \ + "stdout=serial,vga\0" \ + "autoload=n\0" \ "" #else /* defined(CONFIG_ARCHES) */ #define CONFIG_EXTRA_ENV_SETTINGS \ @@ -675,4 +687,23 @@ } #endif +#define CONFIG_VIDEO + +#ifdef CONFIG_VIDEO +#define CONFIG_BIOSEMU /* x86 bios emulator for vga bios */ +#define CONFIG_VIDEO_VESA +#define VIDEO_IO_OFFSET0xd800 +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS VIDEO_IO_OFFSET +#define CONFIG_VIDEO_SW_CURSOR +#define CONFIG_VIDEO_LOGO +#define CONFIG_CFB_CONSOLE +#define CONFIG_SPLASH_SCREEN +#define CONFIG_VGA_AS_SINGLE_DEVICE +#define CONFIG_CMD_BMP +#endif + +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE +#define CONFIG_FRAMEBUFFER_VESA_MODE 0x114 +#define CONFIG_CMD_TFTPPUT + #endif /* __CONFIG_H */ -- >>> >>> Could you also post the codes that actually run the vga bios on ppc >>> target? I may find another non-x86 board to test. >> >> It is all there - I am using the existing support. If you see >> pci_run_vga_bios() it calls biosemu_run() in the emulation case. > > Sorry I mean the complete canyonlands codes which calls > pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called > by chromebook_link. And do you think the int15_handler() required by > the biosemu needs to be common? This series is at u-boot-x86/vesa. You can see the call from the vesa video driver, vesa_fb.c. Re int15_handler(), yes I think it should be, but so far I haven't needed it. I think the ROM access code can be made more common, but I left that task for now. > >> Re your other question I was looking for the VGA enable bit, as I >> remembered it from years ago. It doesn't seem to be needed for that >> platforms I have tested. But if it is generally needed we should add >> it. > > Which platform do you use? I doubt the VGA enable bit only affects x86 > as it opens the A and I/O address decoding which is only > applicable on x86. I'm only using glacier and link so far. I suspect there might be something wrong as only one of my video cards works fully on glacier - another once gives a snowy picture. > >> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is >> called. I wonder if you haven't enabled the ROM BAR? I initially got >> the same result as you. > > Yes, I called pciauto_setup_rom() in my codes. I also verified the > expansion ROM address register has bit0 set to 1 which means enabled. And you still can't see the ROM? Does the BAR give the correct ROM size? Do you enable memory access in the command register? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 03/11] x86: Allow adding of IP checksums
Add a function to add IP checksums.
Signed-off-by: Simon Glass
---
Changes in v2:
- Refactor IP checksum patches
arch/x86/cpu/ip_checksum.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/x86/cpu/ip_checksum.c b/arch/x86/cpu/ip_checksum.c
index 1b529da..ddfc0d7 100644
--- a/arch/x86/cpu/ip_checksum.c
+++ b/arch/x86/cpu/ip_checksum.c
@@ -32,3 +32,24 @@ unsigned short compute_ip_checksum(const void *vptr,
unsigned long nbytes)
sum += (sum >> 16);
return ~sum;
}
+
+unsigned long add_ip_checksums(unsigned long offset, unsigned long sum,
+ unsigned long new)
+{
+ unsigned long checksum;
+
+ sum = ~sum & 0x;
+ new = ~new & 0x;
+ if (offset & 1) {
+ /*
+* byte-swap the sum if it came from an odd offset; since the
+* computation is endian independant this works.
+*/
+ new = ((new >> 8) & 0xff) | ((new << 8) & 0xff00);
+ }
+ checksum = sum + new;
+ if (checksum > 0x)
+ checksum -= 0x;
+
+ return (~checksum) & 0x;
+}
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 05/11] x86: spi: Add device tree support
As a temporary measure before the ICH driver moves over to driver model,
add device tree support to the driver.
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/spi/ich.c| 7 +++
include/configs/x86-common.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index 0379444..fdff158 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -153,6 +153,13 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
return &ich->slave;
}
+struct spi_slave *spi_setup_slave_fdt(const void *blob, int slave_node,
+ int spi_node)
+{
+ /* We only support a single SPI at present */
+ return spi_setup_slave(0, 0, 2000, 0);
+}
+
void spi_free_slave(struct spi_slave *slave)
{
struct ich_spi_slave *ich = to_ich_spi(slave);
diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h
index 4f0a3c5..ecedfc3 100644
--- a/include/configs/x86-common.h
+++ b/include/configs/x86-common.h
@@ -211,6 +211,7 @@
#define CONFIG_CMD_SF_TEST
#define CONFIG_CMD_SPI
#define CONFIG_SPI
+#define CONFIG_OF_SPI_FLASH
/*---
* Environment configuration
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 02/11] x86: Move ipchecksum into common area and rename it
The existing IP checksum function is only accessible to the 'coreboot' cpu.
Move it into the common area and rename it slightly to remove the
abbreviations.
Signed-off-by: Simon Glass
---
Changes in v2:
- Refactor IP checksum patches
arch/x86/cpu/Makefile | 1 +
arch/x86/cpu/coreboot/Makefile | 1 -
arch/x86/cpu/coreboot/ipchecksum.c | 55 -
arch/x86/cpu/coreboot/tables.c | 8 ++--
arch/x86/cpu/ip_checksum.c | 34 +++
arch/x86/include/asm/arch-coreboot/ipchecksum.h | 37 -
arch/x86/include/asm/ip_checksum.h | 16 +++
7 files changed, 55 insertions(+), 97 deletions(-)
delete mode 100644 arch/x86/cpu/coreboot/ipchecksum.c
create mode 100644 arch/x86/cpu/ip_checksum.c
delete mode 100644 arch/x86/include/asm/arch-coreboot/ipchecksum.h
create mode 100644 arch/x86/include/asm/ip_checksum.h
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile
index 62e43c0..eee2289 100644
--- a/arch/x86/cpu/Makefile
+++ b/arch/x86/cpu/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_SYS_COREBOOT) += coreboot/
obj-$(CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE) += ivybridge/
obj-$(CONFIG_NORTHBRIDGE_INTEL_IVYBRIDGE) += ivybridge/
obj-$(CONFIG_INTEL_QUEENSBAY) += queensbay/
+obj-y += ip_checksum.o
obj-y += lapic.o
obj-y += mtrr.o
obj-$(CONFIG_PCI) += pci.o
diff --git a/arch/x86/cpu/coreboot/Makefile b/arch/x86/cpu/coreboot/Makefile
index 35e6cdd..b6e870a 100644
--- a/arch/x86/cpu/coreboot/Makefile
+++ b/arch/x86/cpu/coreboot/Makefile
@@ -16,7 +16,6 @@
obj-y += car.o
obj-y += coreboot.o
obj-y += tables.o
-obj-y += ipchecksum.o
obj-y += sdram.o
obj-y += timestamp.o
obj-$(CONFIG_PCI) += pci.o
diff --git a/arch/x86/cpu/coreboot/ipchecksum.c
b/arch/x86/cpu/coreboot/ipchecksum.c
deleted file mode 100644
index 3340872..000
--- a/arch/x86/cpu/coreboot/ipchecksum.c
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * This file is part of the libpayload project.
- *
- * It has originally been taken from the FreeBSD project.
- *
- * Copyright (c) 2001 Charles Mott
- * Copyright (c) 2008 coresystems GmbH
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include
-#include
-#include
-
-unsigned short ipchksum(const void *vptr, unsigned long nbytes)
-{
- int sum, oddbyte;
- const unsigned short *ptr = vptr;
-
- sum = 0;
- while (nbytes > 1) {
- sum += *ptr++;
- nbytes -= 2;
- }
- if (nbytes == 1) {
- oddbyte = 0;
- ((u8 *)&oddbyte)[0] = *(u8 *) ptr;
- ((u8 *)&oddbyte)[1] = 0;
- sum += oddbyte;
- }
- sum = (sum >> 16) + (sum & 0x);
- sum += (sum >> 16);
- return ~sum;
-}
diff --git a/arch/x86/cpu/coreboot/tables.c b/arch/x86/cpu/coreboot/tables.c
index 92b7528..662af95 100644
--- a/arch/x86/cpu/coreboot/tables.c
+++ b/arch/x86/cpu/coreboot/tables.c
@@ -8,7 +8,7 @@
*/
#include
-#include
+#include
#include
#include
@@ -131,11 +131,11 @@ static int cb_parse_header(void *addr, int len, struct
sysinfo_t *info)
return 0;
/* Make sure the checksums match. */
- if (ipchksum((u16 *) header, sizeof(*header)) != 0)
+ if (compute_ip_checksum((u16 *)header, sizeof(*header)) != 0)
return -1;
- if (ipchksum((u16 *) (ptr + sizeof(*header)),
-header->table_bytes) != header->table_checksum)
+ if (compute_ip_checksum((u16 *)(ptr + sizeof(*header)),
+ header->table_bytes) != header->table_checksum)
return -1;
/* Now, walk the tabl
[U-Boot] [PATCH v2 08/11] x86: Implement a cache for Memory Reference Code parameters
The memory reference code takes a very long time to 'train' its SDRAM
interface, around half a second. To avoid this delay on every boot we can
store the parameters from the last training sessions to speed up the next.
Add an implementation of this, storing the training data in CMOS RAM and
SPI flash.
Signed-off-by: Simon Glass
---
Changes in v2:
- Update for the new CMOS RAM access functions in the RTC
- Add a comment about why both CMOS RAM and SPI flash are used for the cache
arch/x86/cpu/ivybridge/Makefile| 1 +
arch/x86/cpu/ivybridge/mrccache.c | 156 +++
arch/x86/cpu/ivybridge/sdram.c | 253 +
arch/x86/include/asm/arch-ivybridge/mrccache.h | 51 +
arch/x86/include/asm/global_data.h | 3 +
5 files changed, 464 insertions(+)
create mode 100644 arch/x86/cpu/ivybridge/mrccache.c
create mode 100644 arch/x86/include/asm/arch-ivybridge/mrccache.h
diff --git a/arch/x86/cpu/ivybridge/Makefile b/arch/x86/cpu/ivybridge/Makefile
index 0c7efae..3576b83 100644
--- a/arch/x86/cpu/ivybridge/Makefile
+++ b/arch/x86/cpu/ivybridge/Makefile
@@ -14,6 +14,7 @@ obj-y += lpc.o
obj-y += me_status.o
obj-y += model_206ax.o
obj-y += microcode_intel.o
+obj-y += mrccache.o
obj-y += northbridge.o
obj-y += pch.o
obj-y += pci.o
diff --git a/arch/x86/cpu/ivybridge/mrccache.c
b/arch/x86/cpu/ivybridge/mrccache.c
new file mode 100644
index 000..182c995
--- /dev/null
+++ b/arch/x86/cpu/ivybridge/mrccache.c
@@ -0,0 +1,156 @@
+/*
+ * From Coreboot src/southbridge/intel/bd82x6x/mrccache.c
+ *
+ * Copyright (C) 2014 Google Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct mrc_data_container *next_mrc_block(
+ struct mrc_data_container *mrc_cache)
+{
+ /* MRC data blocks are aligned within the region */
+ u32 mrc_size = sizeof(*mrc_cache) + mrc_cache->data_size;
+ if (mrc_size & (MRC_DATA_ALIGN - 1UL)) {
+ mrc_size &= ~(MRC_DATA_ALIGN - 1UL);
+ mrc_size += MRC_DATA_ALIGN;
+ }
+
+ u8 *region_ptr = (u8 *)mrc_cache;
+ region_ptr += mrc_size;
+ return (struct mrc_data_container *)region_ptr;
+}
+
+static int is_mrc_cache(struct mrc_data_container *cache)
+{
+ return cache && (cache->signature == MRC_DATA_SIGNATURE);
+}
+
+/*
+ * Find the largest index block in the MRC cache. Return NULL if none is
+ * found.
+ */
+struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry)
+{
+ struct mrc_data_container *cache, *next;
+ ulong base_addr, end_addr;
+ uint id;
+
+ base_addr = (1ULL << 32) - CONFIG_ROM_SIZE + entry->offset;
+ end_addr = base_addr + entry->length;
+ cache = NULL;
+
+ /* Search for the last filled entry in the region */
+ for (id = 0, next = (struct mrc_data_container *)base_addr;
+is_mrc_cache(next);
+id++) {
+ cache = next;
+ next = next_mrc_block(next);
+ if ((ulong)next >= end_addr)
+ break;
+ }
+
+ if (id-- == 0) {
+ debug("%s: No valid MRC cache found.\n", __func__);
+ return NULL;
+ }
+
+ /* Verify checksum */
+ if (cache->checksum != compute_ip_checksum(cache->data,
+ cache->data_size)) {
+ printf("%s: MRC cache checksum mismatch\n", __func__);
+ return NULL;
+ }
+
+ debug("%s: picked entry %u from cache block\n", __func__, id);
+
+ return cache;
+}
+
+/**
+ * find_next_mrc_cache() - get next cache entry
+ *
+ * @entry: MRC cache flash area
+ * @cache: Entry to start from
+ *
+ * @return next cache entry if found, NULL if we got to the end
+ */
+static struct mrc_data_container *find_next_mrc_cache(struct fmap_entry *entry,
+ struct mrc_data_container *cache)
+{
+ ulong base_addr, end_addr;
+
+ base_addr = (1ULL << 32) - CONFIG_ROM_SIZE + entry->offset;
+ end_addr = base_addr + entry->length;
+
+ cache = next_mrc_block(cache);
+ if ((ulong)cache >= end_addr) {
+ /* Crossed the boundary */
+ cache = NULL;
+ debug("%s: no available entries found\n", __func__);
+ } else {
+ debug("%s: picked next entry from cache block at %p\n",
+ __func__, cache);
+ }
+
+ return cache;
+}
+
+int mrccache_update(struct spi_flash *sf, struct fmap_entry *entry,
+ struct mrc_data_container *cur)
+{
+ struct mrc_data_container *cache;
+ ulong offset;
+ ulong base_addr;
+ int ret;
+
+ /* Find the last used block */
+ base_addr = (1ULL << 32) - CONFIG_ROM_SIZE + entry->offset;
+ debug("Updating MRC cache data\n");
+ cache = mrccache_find_
[U-Boot] [PATCH v2 09/11] x86: config: Enable hook for saving MRC configuration
Add a hook to ensure that this information is saved. Signed-off-by: Simon Glass --- Changes in v2: None include/configs/chromebook_link.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/chromebook_link.h b/include/configs/chromebook_link.h index 7e6d239..6e8b9ef 100644 --- a/include/configs/chromebook_link.h +++ b/include/configs/chromebook_link.h @@ -20,6 +20,7 @@ #define CONFIG_DCACHE_RAM_MRC_VAR_SIZE 0x4000 #define CONFIG_BOARD_EARLY_INIT_F +#define CONFIG_MISC_INIT_R #define CONFIG_NR_DRAM_BANKS 8 #define CONFIG_X86_MRC_ADDR0xfffa -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 07/11] x86: dts: Add SPI flash MRC details for chromebook_link
Correct the SPI flash compatible string, add an alias and specify the
position of the MRC cache, used to store SDRAM training settings for the
Memory Reference Code.
Signed-off-by: Simon Glass
---
Changes in v2:
- Make changes to chromebook_link.dts since link.dts is gone
- Use intel,ich-spi as the compatible string
arch/x86/dts/chromebook_link.dts | 15 ++-
arch/x86/dts/link.dts| 229 +++
2 files changed, 243 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/dts/link.dts
diff --git a/arch/x86/dts/chromebook_link.dts b/arch/x86/dts/chromebook_link.dts
index 9490b16..45ada61 100644
--- a/arch/x86/dts/chromebook_link.dts
+++ b/arch/x86/dts/chromebook_link.dts
@@ -7,6 +7,10 @@
model = "Google Link";
compatible = "google,link", "intel,celeron-ivybridge";
+ aliases {
+ spi0 = "/spi";
+ };
+
config {
silent_console = <0>;
};
@@ -150,11 +154,20 @@
spi {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "intel,ich9";
+ compatible = "intel,ich-spi";
spi-flash@0 {
+ #size-cells = <1>;
+ #address-cells = <1>;
reg = <0>;
compatible = "winbond,w25q64", "spi-flash";
memory-map = <0xff80 0x0080>;
+ rw-mrc-cache {
+ label = "rw-mrc-cache";
+ /* Alignment: 4k (for updating) */
+ reg = <0x003e 0x0001>;
+ type = "wiped";
+ wipe-value = [ff];
+ };
};
};
diff --git a/arch/x86/dts/link.dts b/arch/x86/dts/link.dts
new file mode 100644
index 000..52d8b60
--- /dev/null
+++ b/arch/x86/dts/link.dts
@@ -0,0 +1,229 @@
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+/include/ "serial.dtsi"
+
+/ {
+ model = "Google Link";
+ compatible = "google,link", "intel,celeron-ivybridge";
+
+ aliases {
+ spi0 = "/spi";
+ };
+
+ config {
+ silent_console = <0>;
+ };
+
+ gpioa {
+ compatible = "intel,ich6-gpio";
+ u-boot,dm-pre-reloc;
+ reg = <0 0x10>;
+ bank-name = "A";
+ };
+
+ gpiob {
+ compatible = "intel,ich6-gpio";
+ u-boot,dm-pre-reloc;
+ reg = <0x30 0x10>;
+ bank-name = "B";
+ };
+
+ gpioc {
+ compatible = "intel,ich6-gpio";
+ u-boot,dm-pre-reloc;
+ reg = <0x40 0x10>;
+ bank-name = "C";
+ };
+
+ chosen {
+ stdout-path = "/serial";
+ };
+
+ spd {
+ compatible = "memory-spd";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ elpida_4Gb_1600_x16 {
+ reg = <0>;
+ data = [92 10 0b 03 04 19 02 02
+ 03 52 01 08 0a 00 fe 00
+ 69 78 69 3c 69 11 18 81
+ 20 08 3c 3c 01 40 83 81
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 0f 11 42 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 02 fe 00
+ 11 52 00 00 00 07 7f 37
+ 45 42 4a 32 30 55 47 36
+ 45 42 55 30 2d 47 4e 2d
+ 46 20 30 20 02 fe 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00
+ 00 00 00 00 00 00 00 00];
+ };
+ samsung_4Gb_1600_1.35v_x16 {
+ reg =
[U-Boot] [PATCH v2 10/11] x86: ivybridge: Drop the Kconfig MRC cache information
This is now stored in the device tree. Signed-off-by: Simon Glass --- Changes in v2: None arch/x86/cpu/ivybridge/Kconfig | 28 1 file changed, 28 deletions(-) diff --git a/arch/x86/cpu/ivybridge/Kconfig b/arch/x86/cpu/ivybridge/Kconfig index afca957..e4595be 100644 --- a/arch/x86/cpu/ivybridge/Kconfig +++ b/arch/x86/cpu/ivybridge/Kconfig @@ -26,20 +26,6 @@ config CACHE_MRC_SIZE_KB int default 256 -config MRC_CACHE_BASE - hex - default 0xff80 - -config MRC_CACHE_LOCATION - hex - depends on !CHROMEOS - default 0x1ec000 - -config MRC_CACHE_SIZE - hex - depends on !CHROMEOS - default 0x1 - config DCACHE_RAM_BASE hex default 0xff7f @@ -64,20 +50,6 @@ config CACHE_MRC_SIZE_KB int default 512 -config MRC_CACHE_BASE - hex - default 0xff80 - -config MRC_CACHE_LOCATION - hex - depends on !CHROMEOS - default 0x37 - -config MRC_CACHE_SIZE - hex - depends on !CHROMEOS - default 0x1 - config DCACHE_RAM_BASE hex default 0xff7e -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 01/11] x86: dts: Add compatible string for Intel ICH9 SPI controller
Add this to the enum so that we can use the various fdtdec functions. A
later commit will move this driver to driver model.
Signed-off-by: Simon Glass
---
Changes in v2:
- Use intel,ich-spi as the compatible string
include/fdtdec.h | 1 +
lib/fdtdec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 4901c0d..de46562 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -172,6 +172,7 @@ enum fdt_compat_id {
COMPAT_INTEL_MODEL_206AX, /* Intel Model 206AX CPU */
COMPAT_INTEL_GMA, /* Intel Graphics Media Accelerator */
COMPAT_AMS_AS3722, /* AMS AS3722 PMIC */
+ COMPAT_INTEL_ICH_SPI, /* Intel ICH7/9 SPI controller */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 487122e..e989241 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -83,6 +83,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(INTEL_MODEL_206AX, "intel,model-206ax"),
COMPAT(INTEL_GMA, "intel,gma"),
COMPAT(AMS_AS3722, "ams,as3722"),
+ COMPAT(INTEL_ICH_SPI, "intel,ich-spi"),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/11] x86: rtc: mc146818: Add helpers to read/write CMOS RAM
On x86 we use CMOS RAM to read and write some settings. Add basic support
for this, including access to registers 128-255.
Signed-off-by: Simon Glass
---
Changes in v2:
- Adjust the mc146818 driver instead of adding a new cmos.h header
drivers/rtc/mc146818.c | 53 +-
include/rtc.h | 32 ++
2 files changed, 71 insertions(+), 14 deletions(-)
diff --git a/drivers/rtc/mc146818.c b/drivers/rtc/mc146818.c
index 39e6041..b506b16 100644
--- a/drivers/rtc/mc146818.c
+++ b/drivers/rtc/mc146818.c
@@ -27,9 +27,6 @@
/* Set this to 1 to clear the CMOS RAM */
#define CLEAR_CMOS 0
-static uchar rtc_read (uchar reg);
-static void rtc_write (uchar reg, uchar val);
-
#define RTC_PORT_MC146818 CONFIG_SYS_ISA_IO_BASE_ADDRESS + 0x70
#define RTC_SECONDS0x00
#define RTC_SECONDS_ALARM 0x01
@@ -133,32 +130,60 @@ void rtc_reset (void)
/* - */
-#ifdef CONFIG_SYS_RTC_REG_BASE_ADDR
/*
* use direct memory access
*/
-static uchar rtc_read (uchar reg)
+int rtc_read(int reg)
{
+#ifdef CONFIG_SYS_RTC_REG_BASE_ADDR
return in8(CONFIG_SYS_RTC_REG_BASE_ADDR + reg);
+#else
+ int ofs = 0;
+
+ if (reg >= 128) {
+ ofs = 2;
+ reg -= 128;
+ }
+ out8(RTC_PORT_MC146818 + ofs, reg);
+
+ return in8(RTC_PORT_MC146818 + ofs + 1);
+#endif
}
-static void rtc_write (uchar reg, uchar val)
+void rtc_write(int reg, uchar val)
{
+#ifdef CONFIG_SYS_RTC_REG_BASE_ADDR
out8(CONFIG_SYS_RTC_REG_BASE_ADDR + reg, val);
-}
#else
-static uchar rtc_read (uchar reg)
+ int ofs = 0;
+
+ if (reg >= 128) {
+ ofs = 2;
+ reg -= 128;
+ }
+ out8(RTC_PORT_MC146818 + ofs, reg);
+ out8(RTC_PORT_MC146818 + ofs + 1, val);
+#endif
+}
+
+u32 rtc_read32(int reg)
{
- out8(RTC_PORT_MC146818,reg);
- return in8(RTC_PORT_MC146818 + 1);
+ u32 value = 0;
+ int i;
+
+ for (i = 0; i < sizeof(value); i++)
+ value |= rtc_read(reg + i) << (i << 3);
+
+ return value;
}
-static void rtc_write (uchar reg, uchar val)
+void rtc_write32(int reg, u32 value)
{
- out8(RTC_PORT_MC146818,reg);
- out8(RTC_PORT_MC146818+1, val);
+ int i;
+
+ for (i = 0; i < sizeof(value); i++)
+ rtc_write(reg + i, (value >> (i << 3)) & 0xff);
}
-#endif
void rtc_init(void)
{
diff --git a/include/rtc.h b/include/rtc.h
index d11aa8b..b6df1f4 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -51,6 +51,38 @@ unsigned long mktime (unsigned int, unsigned int, unsigned
int,
unsigned int, unsigned int, unsigned int);
/**
+ * rtc_read() - Read an 8-bit register
+ *
+ * @reg: Register to read
+ * @return value read
+ */
+int rtc_read(int reg);
+
+/**
+ * rtc_write() - Write an 8-bit register
+ *
+ * @reg: Register to write
+ * @value: Value to write
+ */
+void rtc_write(int reg, uchar val);
+
+/**
+ * rtc_read32() - Read a 32-bit value from the RTC
+ *
+ * @reg: Offset to start reading from
+ * @return value read
+ */
+u32 rtc_read32(int reg);
+
+/**
+ * rtc_write32() - Write a 32-bit value to the RTC
+ *
+ * @reg: Register to start writing to
+ * @value: Value to write
+ */
+void rtc_write32(int reg, u32 value);
+
+/**
* rtc_init() - Set up the real time clock ready for use
*/
void rtc_init(void);
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 11/11] x86: config: chromebook_link: Enable environment
Enable an environment area. Signed-off-by: Simon Glass --- Changes in v2: None include/configs/chromebook_link.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/configs/chromebook_link.h b/include/configs/chromebook_link.h index 6e8b9ef..7b460e8 100644 --- a/include/configs/chromebook_link.h +++ b/include/configs/chromebook_link.h @@ -64,6 +64,13 @@ #define CONFIG_CMD_CROS_EC #define CONFIG_ARCH_EARLY_INIT_R +#undef CONFIG_ENV_IS_NOWHERE +#undef CONFIG_ENV_SIZE +#define CONFIG_ENV_SIZE0x1000 +#define CONFIG_ENV_SECT_SIZE 0x1000 +#define CONFIG_ENV_IS_IN_SPI_FLASH +#define CONFIG_ENV_OFFSET 0x003f8000 + #define CONFIG_STD_DEVICES_SETTINGS "stdin=usbkbd,vga,serial\0" \ "stdout=vga,serial\0" \ "stderr=vga,serial\0" -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 06/11] Allow architecture-specific memory reservation
All memory to be reserved for use after relocation by adding a new call
to perform this reservation.
Signed-off-by: Simon Glass
---
Changes in v2: None
common/board_f.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/common/board_f.c b/common/board_f.c
index 3a4b32c..215108b 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -807,6 +807,12 @@ static int initf_dm(void)
return 0;
}
+/* Architecture-specific memory reservation */
+__weak int reserve_arch(void)
+{
+ return 0;
+}
+
static init_fnc_t init_sequence_f[] = {
#ifdef CONFIG_SANDBOX
setup_ram_buf,
@@ -970,6 +976,7 @@ static init_fnc_t init_sequence_f[] = {
setup_machine,
reserve_global_data,
reserve_fdt,
+ reserve_arch,
reserve_stacks,
setup_dram_config,
show_dram_config,
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/11] Add support for caching Memory Reference Code data
Since the memory reference code is so slow on x86, add a feature to bypass this, storing the previous parameters in SPI flash. This saves around 500ms on each boot. Also enable a SPI flash environment. Changes in v2: - Use intel,ich-spi as the compatible string - Refactor IP checksum patches - Refactor IP checksum patches - Adjust the mc146818 driver instead of adding a new cmos.h header - Make changes to chromebook_link.dts since link.dts is gone - Use intel,ich-spi as the compatible string - Update for the new CMOS RAM access functions in the RTC - Add a comment about why both CMOS RAM and SPI flash are used for the cache Simon Glass (11): x86: dts: Add compatible string for Intel ICH9 SPI controller x86: Move ipchecksum into common area and rename it x86: Allow adding of IP checksums x86: rtc: mc146818: Add helpers to read/write CMOS RAM x86: spi: Add device tree support Allow architecture-specific memory reservation x86: dts: Add SPI flash MRC details for chromebook_link x86: Implement a cache for Memory Reference Code parameters x86: config: Enable hook for saving MRC configuration x86: ivybridge: Drop the Kconfig MRC cache information x86: config: chromebook_link: Enable environment arch/x86/cpu/Makefile | 1 + arch/x86/cpu/coreboot/Makefile | 1 - arch/x86/cpu/coreboot/ipchecksum.c | 55 -- arch/x86/cpu/coreboot/tables.c | 8 +- arch/x86/cpu/ip_checksum.c | 55 ++ arch/x86/cpu/ivybridge/Kconfig | 28 --- arch/x86/cpu/ivybridge/Makefile | 1 + arch/x86/cpu/ivybridge/mrccache.c | 156 +++ arch/x86/cpu/ivybridge/sdram.c | 253 arch/x86/dts/chromebook_link.dts| 15 +- arch/x86/dts/link.dts | 229 + arch/x86/include/asm/arch-coreboot/ipchecksum.h | 37 arch/x86/include/asm/arch-ivybridge/mrccache.h | 51 + arch/x86/include/asm/global_data.h | 3 + arch/x86/include/asm/ip_checksum.h | 16 ++ common/board_f.c| 7 + drivers/rtc/mc146818.c | 53 +++-- drivers/spi/ich.c | 7 + include/configs/chromebook_link.h | 8 + include/configs/x86-common.h| 1 + include/fdtdec.h| 1 + include/rtc.h | 32 +++ lib/fdtdec.c| 1 + 23 files changed, 879 insertions(+), 140 deletions(-) delete mode 100644 arch/x86/cpu/coreboot/ipchecksum.c create mode 100644 arch/x86/cpu/ip_checksum.c create mode 100644 arch/x86/cpu/ivybridge/mrccache.c create mode 100644 arch/x86/dts/link.dts delete mode 100644 arch/x86/include/asm/arch-coreboot/ipchecksum.h create mode 100644 arch/x86/include/asm/arch-ivybridge/mrccache.h create mode 100644 arch/x86/include/asm/ip_checksum.h -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support
Hi Simon, On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass wrote: > Hi Bin, > > On 7 January 2015 at 23:18, Bin Meng wrote: >> Hi Simon, >> >> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass wrote: >>> NOT TO APPLY >>> >>> This shows how to enable video for the glacier board, as an example of the >>> emulator working on a VESA-compliant graphics card. >>> >>> Signed-off-by: Simon Glass >>> --- >>> >>> include/configs/canyonlands.h | 31 +++ >>> 1 file changed, 31 insertions(+) >>> >>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h >>> index 7a1499d..c55e076 100644 >>> --- a/include/configs/canyonlands.h >>> +++ b/include/configs/canyonlands.h >>> @@ -133,6 +133,9 @@ >>> #define CONFIG_SYS_NOR_CS 0 /* NOR chip connected to >>> CSx */ >>> #define CONFIG_SYS_NAND_CS 3 /* NAND chip connected to >>> CSx */ >>> >>> +#define CONFIG_CONSOLE_MUX >>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV >>> + >>> /*--- >>> * FLASH related >>> *--*/ >>> @@ -359,6 +362,15 @@ >>> "ramdisk_addr=fc20\0" \ >>> "pciconfighost=1\0" \ >>> "pcie_mode=RP:RP\0" \ >>> + "eth1addr=00:01:ec:00:f4:9d\0" \ >>> + "eth2addr=00:01:ec:00:f4:9e\0" \ >>> + "eth3addr=00:01:ec:00:f4:9f\0" \ >>> + "ethact=ppc_4xx_eth0\0" \ >>> + "ethaddr=00:01:ec:00:f4:9c\0" \ >>> + "stderr=serial\0" \ >>> + "stdin=serial\0" \ >>> + "stdout=serial,vga\0" \ >>> + "autoload=n\0" \ >>> "" >>> #else /* defined(CONFIG_ARCHES) */ >>> #define CONFIG_EXTRA_ENV_SETTINGS \ >>> @@ -675,4 +687,23 @@ >>> } >>> #endif >>> >>> +#define CONFIG_VIDEO >>> + >>> +#ifdef CONFIG_VIDEO >>> +#define CONFIG_BIOSEMU /* x86 bios emulator for vga bios */ >>> +#define CONFIG_VIDEO_VESA >>> +#define VIDEO_IO_OFFSET0xd800 >>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS VIDEO_IO_OFFSET >>> +#define CONFIG_VIDEO_SW_CURSOR >>> +#define CONFIG_VIDEO_LOGO >>> +#define CONFIG_CFB_CONSOLE >>> +#define CONFIG_SPLASH_SCREEN >>> +#define CONFIG_VGA_AS_SINGLE_DEVICE >>> +#define CONFIG_CMD_BMP >>> +#endif >>> + >>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE >>> +#define CONFIG_FRAMEBUFFER_VESA_MODE 0x114 >>> +#define CONFIG_CMD_TFTPPUT >>> + >>> #endif /* __CONFIG_H */ >>> -- >> >> Could you also post the codes that actually run the vga bios on ppc >> target? I may find another non-x86 board to test. > > It is all there - I am using the existing support. If you see > pci_run_vga_bios() it calls biosemu_run() in the emulation case. Sorry I mean the complete canyonlands codes which calls pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called by chromebook_link. And do you think the int15_handler() required by the biosemu needs to be common? > Re your other question I was looking for the VGA enable bit, as I > remembered it from years ago. It doesn't seem to be needed for that > platforms I have tested. But if it is generally needed we should add > it. Which platform do you use? I doubt the VGA enable bit only affects x86 as it opens the A and I/O address decoding which is only applicable on x86. > For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is > called. I wonder if you haven't enabled the ROM BAR? I initially got > the same result as you. Yes, I called pciauto_setup_rom() in my codes. I also verified the expansion ROM address register has bit0 set to 1 which means enabled. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] samsung: board: support eMMC reset using DT
On Thu, 2015-01-08 at 14:44 +0900, Joonyoung Shim wrote:
> Some exynos boards require special handling of SD4_nRESET_OUT line for
> eMMC memory to perform complete reboot e.g. Odroid X2/U3/XU3 boards.
>
> This will support eMMC reset using DT from reset_misc of samsung common
> board file and each board files can support eMMC reset on non DT case.
>
> Signed-off-by: Joonyoung Shim
> diff --git a/doc/device-tree-bindings/exynos/emmc-reset.txt
> b/doc/device-tree-bindings/exynos/emmc-reset.txt
> new file mode 100644
> index 000..e48e508
> --- /dev/null
> +++ b/doc/device-tree-bindings/exynos/emmc-reset.txt
> @@ -0,0 +1,15 @@
> +* Samsung eMMC reset
> +
> +Some exynos boards require special handling of SD4_nRESET_OUT line for eMMC
> +memory to perform complete reboot.
Nitpick, on XU3 the line you apparently need to twiddle is
SD0_nRESET_OUT.
Is this type of usage of this pin specific to the Odroid Exynos boards
or potentially on more boards? (Sorry for the simple questions, but my
exynos documentation just says the line exists not what its intended
usage is).
Fwiw, I did a quick check in the linux code and it doesn't seem to be
using those pins for currently for any boards. However my X2 does
successfully reset/reboot in u-boot and linux, so it seems optional
there. The XU3 does fail to reset itself, so it seems required for that
board.
> +Required properties:
> +- compatible: should be "samsung,emmc-reset"
> +- reset-gpio: gpio chip for eMMC reset.
> +
> +Example:
> +
> +emmc-reset {
> +compatible = "samsung,emmc-reset";
> +reset-gpio = <&gpk1 2 0>;
> +};
--
Sjoerd Simons
Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] board/T1040qds: Add VSC9953 support for T1040qds board
On 12/19/2014 09:02 AM, Codrin Ciubotariu wrote: > This patch configures and initializes the L2 switch on T1040QDS board. > The L2 switch ports must be initialized according to the SerDes > protocols. > > Signed-off-by: Codrin Ciubotariu > Change-Id: I329f9cc1b1be745da23151e78831d8a3219b7f97 > --- > board/freescale/t1040qds/eth.c | 93 > ++ > include/configs/T1040QDS.h | 4 ++ > 2 files changed, 97 insertions(+) > > diff --git a/board/freescale/t1040qds/eth.c b/board/freescale/t1040qds/eth.c > index 2f8e753..ba6f518 100644 > --- a/board/freescale/t1040qds/eth.c > +++ b/board/freescale/t1040qds/eth.c > @@ -18,6 +18,9 @@ > #include > #include > #include > +#ifdef CONFIG_VSC9953 > +#include > +#endif Don't put ifdef for header file. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Nokia RX-51: Do not call secure PPA routine on non secure devices
Hi Pali Rohár, Have you tested this patch on a secure device (as the nokia n900)? Regards, Georges Le 08/01/2015 10:11, Pali Rohár a écrit : Since commit 41623c91b09a0c865fab41acdaff30f060f29ad6 u-boot running in qemu is crashing in function do_omap3_emu_romcode_call(). RX-51 board uses this function for Cortex-A8 errata 430973 workaround (Set IBE bit in ACR) which is needed only on real secure device and not in qemu. This board patch just disable calling secure PPA routine on non secure devices. Qemu implements GP device and with this patch u-boot is working in qemu again. Signed-off-by: Pali Rohár --- board/nokia/rx51/rx51.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c index b6b8ad6..08fcaf2 100644 --- a/board/nokia/rx51/rx51.c +++ b/board/nokia/rx51/rx51.c @@ -422,8 +422,12 @@ int misc_init_r(void) /* * Cortex-A8(r1p0..r1p2) errata 430973 workaround * Set IBE bit in Auxiliary Control Register +* +* Call this routine only on real secure device +* Qemu does not implement secure PPA and crash */ - omap3_update_aux_cr_secure_rx51(1 << 6, 0); + if (get_device_type() == HS_DEVICE) + omap3_update_aux_cr_secure_rx51(1 << 6, 0); return 0; } ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] checkpatch warning on Kconfig
Guys, I think this is a false positive warning. When I add a config to Kconfig, checkpatch complains WARNING: please write a paragraph that describes the config symbol fully #70: FILE: arch/powerpc/cpu/mpc85xx/Kconfig:33: +config TARGET_FOO_FOO total: 0 errors, 1 warnings, 0 checks, 2276 lines checked How can I get rid of this one? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gpt: Fix the protective MBR partition size
(+ Lukasz)
Interesting - I'll defer to Lukasz...
Thanks, Steve
On 15-01-08 03:26 AM, Maxime Ripard wrote:
According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata
B), the protective MBR partition record size must be set to the size of the
disk minus one, in LBAs.
However, the current code was setting the size as the total number of LBAs on
the disk, resulting in an off-by-one error.
This confused the AM335x ROM code, and will probably confuse other tools as
well.
Signed-off-by: Maxime Ripard
---
disk/part_efi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 612f0926b62b..5ca17c138e96 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -240,7 +240,7 @@ static int set_protective_mbr(block_dev_desc_t *dev_desc)
p_mbr->signature = MSDOS_MBR_SIGNATURE;
p_mbr->partition_record[0].sys_ind = EFI_PMBR_OSTYPE_EFI_GPT;
p_mbr->partition_record[0].start_sect = 1;
- p_mbr->partition_record[0].nr_sects = (u32) dev_desc->lba;
+ p_mbr->partition_record[0].nr_sects = (u32) dev_desc->lba - 1;
/* Write MBR sector to the MMC device */
if (dev_desc->block_write(dev_desc->dev, 0, 1, p_mbr) != 1) {
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mxsboot : Support of 224-bytes OOB area length
Add support for the NAND Flash chip with page size of 4096+224-bytes OOB area
length
For example Micron MT29F4G08 NAND flash device defines a OOB area which is
224 bytes long (oobsize).
Signed-off-by: Alexandre Coffignal
---
tools/mxsboot.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index 90b2173..6d48cfb 100644
--- a/tools/mxsboot.c
+++ b/tools/mxsboot.c
@@ -142,6 +142,9 @@ static inline uint32_t mx28_nand_get_ecc_strength(uint32_t
page_data_size,
if (page_oob_size == 218)
return 16;
+
+ if (page_oob_size == 224)
+ return 16;
}
return 0;
@@ -269,6 +272,9 @@ static struct mx28_nand_fcb *mx28_nand_get_fcb(uint32_t
size)
} else if (nand_oobsize == 218) {
fcb->ecc_block_n_ecc_type = 8;
fcb->ecc_block_0_ecc_type = 8;
+ } else if (nand_oobsize == 224) {
+ fcb->ecc_block_n_ecc_type = 8;
+ fcb->ecc_block_0_ecc_type = 8;
}
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sunxi video support patches (edid, lcd and vga support) have been queued up in u-boot-sunxi/next
Hi Ian, Anatolij, Thanks to Anatolij's hard work on reviewing all the patches today, everything is ready to go upstream now, and I've queued everything up in u-boot-sunxi/next for merging into v2015.04 once the merge window opens. I've also rebased u-boot-sunxi/next on top of current master, and as such done a forces push to u-boot-sunxi/next. Regards, Hans p.s. "Everything" excludes the 3 patch lvds lcd panel set I send a couple of days ago, I've prepared a v2 addressing Ian's concerns with v1. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] sunxi: video: Add lvds support
Add support for lvds lcd panels
Signed-off-by: Hans de Goede
---
arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 2 ++
arch/arm/include/asm/arch-sunxi/display.h | 12 +
arch/arm/include/asm/arch-sunxi/gpio.h| 1 +
board/sunxi/Kconfig | 27 +++
drivers/video/sunxi_display.c | 37 +--
5 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
index 64b5c38..70b789e 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
@@ -284,6 +284,8 @@ struct sunxi_ccm_reg {
/* Enable / disable both ch1 sclk1 and sclk2 at the same time */
#define CCM_LCD_CH1_CTRL_GATE (0x1 << 31 | 0x1 << 15)
+#define CCM_LVDS_CTRL_RST (1 << 0)
+
#define CCM_HDMI_CTRL_M(n) n) - 1) & 0xf) << 0)
#define CCM_HDMI_CTRL_PLL_MASK (3 << 24)
#define CCM_HDMI_CTRL_PLL3 (0 << 24)
diff --git a/arch/arm/include/asm/arch-sunxi/display.h
b/arch/arm/include/asm/arch-sunxi/display.h
index 19582c1..6f586f1 100644
--- a/arch/arm/include/asm/arch-sunxi/display.h
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -91,6 +91,9 @@ struct sunxi_lcdc_reg {
u8 res3[0x44]; /* 0xac */
u32 tcon1_io_polarity; /* 0xf0 */
u32 tcon1_io_tristate; /* 0xf4 */
+ u8 res4[0x128]; /* 0xf8 */
+ u32 lvds_ana0; /* 0x220 */
+ u32 lvds_ana1; /* 0x224 */
};
struct sunxi_hdmi_reg {
@@ -244,12 +247,21 @@ struct sunxi_tve_reg {
#define SUNXI_LCDC_TCON0_TIMING_H_TOTAL(n) (((n) - 1) << 16)
#define SUNXI_LCDC_TCON0_TIMING_V_BP(n)(((n) - 1) << 0)
#define SUNXI_LCDC_TCON0_TIMING_V_TOTAL(n) (((n) * 2) << 16)
+#define SUNXI_LCDC_TCON0_LVDS_INTF_BITWIDTH(n) ((n) << 26)
+#define SUNXI_LCDC_TCON0_LVDS_INTF_ENABLE (1 << 31)
+#define SUNXI_LCDC_TCON0_IO_POL_DCLK_PHASE0(0 << 28)
+#define SUNXI_LCDC_TCON0_IO_POL_DCLK_PHASE60 (1 << 28)
+#define SUNXI_LCDC_TCON0_IO_POL_DCLK_PHASE120 (2 << 28)
#define SUNXI_LCDC_TCON1_CTRL_CLK_DELAY(n) (((n) & 0x1f) << 4)
#define SUNXI_LCDC_TCON1_CTRL_ENABLE (1 << 31)
#define SUNXI_LCDC_TCON1_TIMING_H_BP(n)(((n) - 1) << 0)
#define SUNXI_LCDC_TCON1_TIMING_H_TOTAL(n) (((n) - 1) << 16)
#define SUNXI_LCDC_TCON1_TIMING_V_BP(n)(((n) - 1) << 0)
#define SUNXI_LCDC_TCON1_TIMING_V_TOTAL(n) (((n) * 2) << 16)
+#define SUNXI_LCDC_LVDS_ANA0 0x3f31
+#define SUNXI_LCDC_LVDS_ANA0_UPDATE(1 << 22)
+#define SUNXI_LCDC_LVDS_ANA1_INIT1 (0x1f << 26 | 0x1f << 10)
+#define SUNXI_LCDC_LVDS_ANA1_INIT2 (0x1f << 16 | 0x1f << 00)
/*
* HDMI register constants.
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 9438f5a..71cc879 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -151,6 +151,7 @@ enum sunxi_gpio_number {
#define SUNXI_GPC6_SDC23
#define SUNXI_GPD0_LCD02
+#define SUNXI_GPD0_LVDS0 3
#define SUNXI_GPF0_SDC02
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 8782394..e5aa05b 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -345,6 +345,33 @@ config VIDEO_LCD_BL_PWM
Set the backlight pwm pin for the LCD panel. This takes a string in the
format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
+
+# Note only one of these may be selected at a time! But hidden choices are
+# not supported by Kconfig
+config VIDEO_LCD_IF_PARALLEL
+ bool
+
+config VIDEO_LCD_IF_LVDS
+ bool
+
+
+choice
+ prompt "LCD panel support"
+ depends on VIDEO
+ ---help---
+ Select which type of LCD panel to support.
+
+config VIDEO_LCD_PANEL_PARALLEL
+ bool "Generic parallel interface LCD panel"
+ select VIDEO_LCD_IF_PARALLEL
+
+config VIDEO_LCD_PANEL_LVDS
+ bool "Generic lvds interface LCD panel"
+ select VIDEO_LCD_IF_LVDS
+
+endchoice
+
+
config USB_KEYBOARD
boolean "Enable USB keyboard support"
default y
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 8241492..47d820d 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -339,8 +339,13 @@ static void sunxi_lcdc_pll_set(int tcon, int dotclock,
int best_double = 0;
if (tcon == 0) {
+#ifdef CONFIG_VIDEO_LCD_IF_PARALLEL
min_m = 6;
max_m = 127;
+#endif
+#ifdef CONFIG_VIDEO_LCD_IF_LVDS
+ min_m = max_m = 7;
+#endif
} else {
min_m = 1;
max_m = 15;
@@ -420,6 +425,9 @@ static void sunxi_lcdc_init(void)
/* Clock on
[U-Boot] [PATCH v2 2/2] sunxi: video: Add support for Hitachi tx18d42vm LCD panels
Hitachi tx18d42vm LCD panels have an onboard controller which needs some
initialization via spi for the panel to become functional as a regular LVDS
panel.
Signed-off-by: Hans de Goede
---
board/sunxi/Kconfig | 4 +++
drivers/video/Makefile | 2 +-
drivers/video/sunxi_display.c | 5 +++
drivers/video/sunxi_lcd_panel.c | 68 +
drivers/video/sunxi_lcd_panel.h | 9 ++
5 files changed, 87 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/sunxi_lcd_panel.c
create mode 100644 drivers/video/sunxi_lcd_panel.h
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index e5aa05b..adee5ed 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -369,6 +369,10 @@ config VIDEO_LCD_PANEL_LVDS
bool "Generic lvds interface LCD panel"
select VIDEO_LCD_IF_LVDS
+config VIDEO_LCD_PANEL_HITACHI_TX18D42VM
+ bool "Hitachi tx18d42vm LCD panel"
+ select VIDEO_LCD_IF_LVDS
+
endchoice
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 42b1eaa..d4fe1aa 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -39,7 +39,7 @@ obj-$(CONFIG_VIDEO_SANDBOX_SDL) += sandbox_sdl.o
obj-$(CONFIG_VIDEO_SED13806) += sed13806.o
obj-$(CONFIG_VIDEO_SM501) += sm501.o
obj-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o videomodes.o
-obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o videomodes.o
+obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o sunxi_lcd_panel.o videomodes.o
obj-$(CONFIG_VIDEO_TEGRA) += tegra.o
obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
obj-$(CONFIG_VIDEO_X86) += x86_fb.o
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 47d820d..c3fc732 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include "sunxi_lcd_panel.h"
#include "videomodes.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -487,6 +488,10 @@ static void sunxi_lcdc_panel_enable(void)
gpio_request(pin, "lcd_power");
gpio_direction_output(pin, 1);
}
+
+#ifdef CONFIG_VIDEO_LCD_PANEL_HITACHI_TX18D42VM
+ sunxi_lcd_panel_hitachi_tx18d42vm_init();
+#endif
}
static void sunxi_lcdc_backlight_enable(void)
diff --git a/drivers/video/sunxi_lcd_panel.c b/drivers/video/sunxi_lcd_panel.c
new file mode 100644
index 000..9ebaff2
--- /dev/null
+++ b/drivers/video/sunxi_lcd_panel.c
@@ -0,0 +1,68 @@
+/*
+ * LCD panel driver for Allwinner SoCs.
+ *
+ * (C) Copyright 2015 Hans de Goede
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+
+#include
+#include
+#include
+
+#ifdef CONFIG_VIDEO_LCD_PANEL_HITACHI_TX18D42VM
+
+#define SPI_CS SUNXI_GPA(0)
+#define SPI_CLKSUNXI_GPA(1)
+#define SPI_MOSI SUNXI_GPA(2)
+
+/*
+ * Very simple write only SPI support, this does not use the generic SPI infra
+ * because that assumes R/W SPI, requiring a MISO pin. Also the necessary glue
+ * code alone would be larger then this minimal version.
+ */
+
+static void sunxi_lcd_panel_spi_write(unsigned int data, int bits)
+{
+ int i, offset;
+
+ gpio_direction_output(SPI_CS, 0);
+ for (i = 0; i < bits; i++) {
+ gpio_direction_output(SPI_CLK, 0);
+ offset = (bits - 1) - i;
+ gpio_direction_output(SPI_MOSI, (data >> offset) & 1);
+ udelay(2);
+ gpio_direction_output(SPI_CLK, 1);
+ udelay(2);
+ }
+ gpio_direction_output(SPI_CS, 1);
+ udelay(2);
+}
+
+void sunxi_lcd_panel_hitachi_tx18d42vm_init(void)
+{
+ const u16 init_data[] = {
+ 0x0029, /* reset */
+ 0x0025, /* standby */
+ 0x0840, /* enable normally black */
+ 0x0430, /* enable FRC/dither */
+ 0x385f, /* enter test mode(1) */
+ 0x3ca4, /* enter test mode(2) */
+ 0x3409, /* enable SDRRS, enlarge OE width */
+ 0x4041, /* adopt 2 line / 1 dot */
+ };
+ int i;
+
+ mdelay(50); /* Wait for lcd controller power on */
+
+ for (i = 0; i < ARRAY_SIZE(init_data); i++)
+ sunxi_lcd_panel_spi_write(init_data[i], 16);
+
+ mdelay(50); /* All the tx18d42vm drivers have a delay here ? */
+
+ sunxi_lcd_panel_spi_write(0x00ad, 16); /* display on */
+}
+
+#endif
diff --git a/drivers/video/sunxi_lcd_panel.h b/drivers/video/sunxi_lcd_panel.h
new file mode 100644
index 000..1fb9f1e
--- /dev/null
+++ b/drivers/video/sunxi_lcd_panel.h
@@ -0,0 +1,9 @@
+/*
+ * LCD panel driver for Allwinner SoCs.
+ *
+ * (C) Copyright 2015 Hans de Goede
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+void sunxi_lcd_panel_hitachi_tx18d42vm_init(void);
--
2.1.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] sunxi: video: Add lvds support
Hi Ian, Anatolij, Here is v2 of the lvds support for sunxi-video. I've reworked how to Kconfig bits are handled as requested by Ian. Anatolij, the second patch in this sets adds support for initializing the lcd controller found on hitachi tx18d42vm lcd panels, this lvds lcd controller needs some poking via a separate spi bus before the panel will do anything. This code is not really sunxi specific, but since sunxi is the only (known) user of such a lcd controller I've chosen to do this in a sunxi specific file for now, with the idea that making the code generic is more easy when we actually have a second user, and thus a better idea of what is needed for a generic implementation. Can we get your ack for this solution? Or let me know if you want me todo something generic right away and then I'll rework the patch. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] sunxi video support patches (edid, lcd and vga support) have been queued up in u-boot-sunxi/next
Hi Ian, Anatolij, Thanks to Anatolij's hard work on reviewing all the patches today, everything is ready to go upstream now, and I've queued everything up in u-boot-sunxi/next for merging into v2015.04 once the merge window opens. I've also rebased u-boot-sunxi/next on top of current master, and as such done a forces push to u-boot-sunxi/next. Regards, Hans p.s. "Everything" excludes the 3 patch lvds lcd panel set I send a couple of days ago, I've prepared a v2 addressing Ian's concerns with v1. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, Please pull this PR. thanks! Jagan. The following changes since commit d622ac39274a949b6445f1bfd92dc1644014388b: powerpc: mpc824x: remove MPC824X cpu support (2015-01-05 12:08:55 -0500) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to adc0fabfd9662fa690e866332cd4277351f991c4: imx:mx6sxsabresd support qspi AHB read (2015-01-09 00:03:28 +0530) Axel Lin (3): spi: designware_spi: Fix detecting FIFO depth spi: cadence_qspi: Fix checking return value of fdt_first_subnode() spi: ftssp010_spi: Simplify code flow in ftssp010_[wait|wait_tx|wait_rx] Marek Vasut (2): dt: socfpga: Rename snps, dw-spi-mmio to snps, dw-apb-ssi dt: socfpga: Replace num-chipselect with num-cs Peng Fan (4): spi:fsl-quadspi support bank register read write mx6sxsabresd: support qspi flash bigger than 16MB qspi:fsl implement AHB read imx:mx6sxsabresd support qspi AHB read arch/arm/dts/socfpga.dtsi | 10 +- drivers/spi/cadence_qspi.c | 2 +- drivers/spi/designware_spi.c | 6 +- drivers/spi/fsl_qspi.c | 297 + drivers/spi/fsl_qspi.h | 15 +++ drivers/spi/ftssp010_spi.c | 36 ++--- include/configs/mx6sxsabresd.h | 8 ++ 7 files changed, 316 insertions(+), 58 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] imx:mx6sxsabresd support qspi AHB read
On 8 January 2015 at 08:10, Peng Fan wrote: > Add CONFIG_SYS_FSL_QSPI_AHB in header file to enable AHB in driver. > In order to count the time, add CONFIG_CMD_TIME. > > Using AHB read can improve the the read speed about 30%. > > AHB read: > => time sf read 0x8f80 0 10 > SF: 1048576 bytes @ 0x0 Read: OK > time: 0.174 seconds > > => time sf read 0x8f80 100 10 > SF: 1048576 bytes @ 0x100 Read: OK > time: 0.174 seconds > > IP read: > => time sf read 0x8f80 0 10 > SF: 1048576 bytes @ 0x0 Read: OK > time: 0.227 seconds > > => time sf read 0x8f80 100 10 > SF: 1048576 bytes @ 0x100 Read: OK > time: 0.227 seconds > > Note: > Quad read is not supported in driver, now. In my side, using AHB and Quad read > can achieve about 16MB/s. Anyway, I have plan to reimplement the driver using > DTB and DM, then make the code cleaner and more feature can be added. > > Signed-off-by: Peng Fan > --- > include/configs/mx6sxsabresd.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h > index b40dc19..fbaae3f 100644 > --- a/include/configs/mx6sxsabresd.h > +++ b/include/configs/mx6sxsabresd.h > @@ -235,6 +235,8 @@ > /* FLASH and environment organization */ > #define CONFIG_SYS_NO_FLASH > > +#define CONFIG_CMD_TIME > + > #define CONFIG_FSL_QSPI > > #ifdef CONFIG_FSL_QSPI > @@ -244,6 +246,7 @@ > #define CONFIG_SPI_FLASH_SPANSION > #define CONFIG_SPI_FLASH_STMICRO > #define CONFIG_SYS_FSL_QSPI_LE > +#define CONFIG_SYS_FSL_QSPI_AHB > #ifdef CONFIG_MX6SX_SABRESD_REVA > #define FSL_QSPI_FLASH_SIZESZ_16M > #else > -- > 1.8.4 > > Applied to u-boot-spi/master thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] qspi:fsl implement AHB read
On 8 January 2015 at 17:10, Peng Fan wrote:
>
> On 1/8/2015 7:21 PM, Jagan Teki wrote:
>>
>> On 8 January 2015 at 15:48, Peng Fan wrote:
>>>
>>> Hi, Jagan
>>>
>>> On 1/8/2015 2:20 PM, Jagan Teki wrote:
On 8 January 2015 at 08:10, Peng Fan wrote:
>
> The QSPI controller in i.MX 6SoloX and Vybrid supports reading data
> using
> IP register and AHB bus.
>
> The original driver only supports reading data from IP interface. The
> IC
> team suggests to use AHB read which is faster then IP read. Using AHB
> read,
> we can directly memcpy, a "missed" access to the buffer will cause the
> controller to clear the buffer and use the SEQID stored in bfgencr
> register
> to initiate a read from flash device.
So for the read connections - controller is connected through IP and
AHB interface
is it? and I'm thinking these two are bus protocols which can use any
peripheral unlike
qspi.
>>>
>>>
>>> Yeah. fsl qspi controller is connected through IP and AHB interface.
>>> register access through IP interface, Data access can use IP interface or
>>> AHB interface. There is a memory mapped region for AHB data read. If
>>> want
>>> to use AHB data read for QSPI, the controller should be configured by
>>> IP
>>> interface, and then can use memcpy to read data. This patch adds the
>>> configuration for using QSPI AHB read, this configuration is dedicated
>>> for
>>> qspi.
>>
>> Yes - I understand.
>>
>> I'm thinking this ahb is a generic but not only specific to qspi the
>> read of this
>> interface should be generic somewhere in arch code so-that fsl_qspi will
>> call
>> those routines on based on the need. - does it make sense?
>
>
> The AHB read function is just memcpy. This original code use "qspi_op_read"
> to read data from IP interface. In this patch, if configured
> CONFIG_FSL_QSPI_AHB_READ, use qsp_ahb_read. This function is very simple, as
> following:
>
> +mcr_reg = qspi_read32(®s->mcr);
>
> +
>
> +qspi_write32(®s->mcr, QSPI_MCR_CLR_RXF_MASK | QSPI_MCR_CLR_TXF_MASK |
>
> +QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE);
>
> +
>
> +/* Read out the data directly from the AHB buffer. */
>
> +memcpy(rxbuf, (u8 *)(q->amba_base + q->sf_addr), len);
>
> +
>
> +qspi_write32(®s->mcr, mcr_reg);
>
>
> It's just a wrapper function to call memcpy and save/restore qspi mcr
> register, nothing else. I think it's not needed to wrap memcpy and move it
> to arch code, since it is simple and contains qspi register save and
> restore.
>
>
> Since AHB bus is 64 bit width, we can not set MCR register using 32bit.
> In
> order to minimize code change, redefine QSPI_MCR_END_CFD_LE to 64bit
> Little
> endian but not 32bit Little endia.
>
> Introduce a new configuration option CONFIG_SYS_FSL_QSPI_AHB. If want
> to
> use AHB read, just define CONFIG_SYS_FSL_QSPI_AHB. If not, just ignore
> it.
> Actually if Vybrid is migrated to use AHB read, this option can be
> removed and
> IP read function can be discared. The reason to introduce this option
> is that only i.MX SOC is tested in my side, no Vybrid platform for me.
So, where did you define?
>>>
>>>
>>> The configuration is defined in board header file in mx6sxsabresd.h,
>>> using
>>> #define CONFIG_SYS_FSL_QSPI_AHB.
>>
>> Yes I saw in 2/2
>>
>>>
> In spi_setup_slave, the original piece code to set AHB is deleted,
> since
> Vybrid platform does not use this to intiate AHB read. Instead, add
> qspi_init_ahb_read function if defined CONFIG_SYS_FSL_QSPI_AHB.
>
> Signed-off-by: Peng Fan
> ---
>drivers/spi/fsl_qspi.c | 137
> +
>drivers/spi/fsl_qspi.h | 15 ++
>2 files changed, 142 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
> index ad4f4ce..5e0b069 100644
> --- a/drivers/spi/fsl_qspi.c
> +++ b/drivers/spi/fsl_qspi.c
> @@ -263,6 +263,110 @@ static void qspi_set_lut(struct fsl_qspi *qspi)
> qspi_write32(®s->lckcr, QSPI_LCKCR_LOCK);
>}
>
> +#if defined(CONFIG_SYS_FSL_QSPI_AHB)
> +/*
> + * If we have changed the content of the flash by writing or erasing,
> + * we need to invalidate the AHB buffer. If we do not do so, we may
> read
> out
> + * the wrong data. The spec tells us reset the AHB domain and Serial
> Flash
> + * domain at the same time.
> + */
> +static inline void qspi_ahb_invalid(struct fsl_qspi *q)
> +{
> + struct fsl_qspi_regs *regs = (struct fsl_qspi_regs
> *)q->reg_base;
> + u32 reg;
> +
> + reg = qspi_read32(®s->mcr);
> + reg |= QSPI_MCR_SWRSTHD_MASK | QSPI_MCR_SWRSTSD_MASK;
> + qspi_write32(®s->mcr, reg);
> +
> + /*
> +* The minimum delay : 1 AHB + 2 SFCK clocks.
> +* Delay 1 us
Re: [U-Boot] [PATCH] arm: vf610: fix boot from SD-card
On 8 Jan 2015, ste...@agner.ch wrote:
> Boot from SD-card (and probably also from NAND) was broken since
> commit d6d07a9bec ("arm: vf610: add NAND support for vf610twr").
It was broke before that when fsl_qspi was added? Or at least that also
added a lot of code. It maybe dependant on the compiler (and hence
binary size).
> It looks like the increased size of U-Boot lead to a situation where
> the boot ROM overwrote its own stack/heap while loading U-Boot from
> the SD-card to the SRAM.
I didn't think of this. That is a possibility.
> However, U-Boot worked fine when loaded through USB serial loader
> directly into SRAM. It looks like loading from SD-card uses other
> stack/heap location then the serial loader (or maybe no stack or heap
> at all).
I have tried various u-boot images with git-bisect. For instance when
the QSPI was added, I had issues. It seems that an image near 220k was
a threshold. The offset in the On-chip SRAM is 0x8000 (from the 'ld'
file) and the imximage prints '3f008000'. So, I think that the offset
takes the breaking point to where we cross from OC-SRAM0 to OC-SRAM1; I
guess a stack maybe located here but it must be fairly small. I thought
that maybe the HAB has a mapping of device memory start/size and didn't
like it when we crossed the boundary.
> This fix moves U-Boot to gfxRAM, which is 512kB in size and is not
> used by the boot ROM nor the SD-card loader of it.
Whatever the issue is, this fixes it for me as well. I would guess that
NAND boot is also not possible or probably anything but serial-download
modes.
Thanks,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Odroid: Add eMMC-reset node on DT
Hi,
On 7 January 2015 at 22:44, Joonyoung Shim wrote:
> This needs for special handling of SD4_nRESET_OUT line for eMMC memory
> to perform complete reboot on Odroid X2/U3 boards.
>
> Signed-off-by: Joonyoung Shim
> ---
> arch/arm/dts/exynos4412-odroid.dts | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/dts/exynos4412-odroid.dts
> b/arch/arm/dts/exynos4412-odroid.dts
> index ecb3e23..519a7dd 100644
> --- a/arch/arm/dts/exynos4412-odroid.dts
> +++ b/arch/arm/dts/exynos4412-odroid.dts
> @@ -90,4 +90,9 @@
> reg = <0x125B 0x100>;
> };
> };
> +
> + emmc-reset {
> + compatible = "samsung,emmc-reset";
> + reset-gpio = <&gpk1 2 0>;
> + };
> };
Shouldn't this go in the relevant sdhci node instead of its own node?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: gadget: pxa25x_udc: fix use-before-initialized bug
> You can use [PATCH RESEND], which is probably much clearer in expressing > the intent. You might add a short note just before the diffstat saying that > you only updated the SoB line and author to match the real deal, but didn't > change the patch contents. I've edited my patch and it's still applies on to top HEAD of master branch, so I've sent fixed version to mailing list. Thank you for mentioning this idea of commentaries before diffstat output, I've never heard about it. > You can read [1] for the finer points of patch submission process, but > TL;DR > it's pretty much the same as Linux ;-) Sounds like a nice joke! In fact, I'm doing my first steps in open-source software, so sending patches to Linux is something like a far dream. But if I reach that stage someday, then I'll be able to say that it's "pretty much the same as for U-Boot". > [1] http://www.denx.de/wiki/U-Boot/Patches#General_Patch_Submission_Rules I've studied [1] yesterday, and looked through it again today, so I hope that I'm doing everything in a right way this time. Best regards, Alex. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] samsung: board: support eMMC reset using DT
Hi Joonyoung,
On 7 January 2015 at 22:44, Joonyoung Shim wrote:
> Some exynos boards require special handling of SD4_nRESET_OUT line for
> eMMC memory to perform complete reboot e.g. Odroid X2/U3/XU3 boards.
>
> This will support eMMC reset using DT from reset_misc of samsung common
> board file and each board files can support eMMC reset on non DT case.
>
> Signed-off-by: Joonyoung Shim
> ---
> board/samsung/common/board.c | 27
> ++
> board/samsung/odroid/odroid.c | 2 +-
> doc/device-tree-bindings/exynos/emmc-reset.txt | 15 ++
> 3 files changed, 43 insertions(+), 1 deletion(-)
> create mode 100644 doc/device-tree-bindings/exynos/emmc-reset.txt
>
> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> index c04ab3c..3218463 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -40,6 +40,8 @@ __weak int exynos_power_init(void)
> return 0;
> }
>
> +__weak void exynos_reset_misc(void) {}
> +
> #if defined CONFIG_EXYNOS_TMU
> /* Boot Time Thermal Analysis for SoC temperature threshold breach */
> static void boot_temp_check(void)
> @@ -400,3 +402,28 @@ int misc_init_r(void)
> return 0;
> }
> #endif
> +
> +void reset_misc(void)
> +{
> +#ifdef CONFIG_OF_CONTROL
I think all Samsung boards have this defined, so this #ifdef can be removed.
> + struct gpio_desc gpio = {};
> + int node;
> +
> + node = fdt_node_offset_by_compatible(gd->fdt_blob, 0,
> + "samsung,emmc-reset");
> + if (node < 0)
> + return;
> +
> + gpio_request_by_name_nodev(gd->fdt_blob, node, "reset-gpio", 0, &gpio,
> + GPIOD_IS_OUT);
> +
> + if (dm_gpio_is_valid(&gpio)) {
> + /* Reset eMMC*/
> + dm_gpio_set_value(&gpio, 0);
> + mdelay(10);
That's a very long reset! Is that what it needs?
> + dm_gpio_set_value(&gpio, 1);
> + }
> +#else
> + exynos_reset_misc();
So I don't think you need this function.
> +#endif
> +}
> diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
> index 3f43e17..db35945 100644
> --- a/board/samsung/odroid/odroid.c
> +++ b/board/samsung/odroid/odroid.c
> @@ -516,7 +516,7 @@ int board_usb_init(int index, enum usb_init_type init)
> }
> #endif
>
> -void reset_misc(void)
> +void exynos_reset_misc(void)
> {
> /* Reset eMMC*/
> gpio_set_value(EXYNOS4X12_GPIO_K12, 0);
> diff --git a/doc/device-tree-bindings/exynos/emmc-reset.txt
> b/doc/device-tree-bindings/exynos/emmc-reset.txt
> new file mode 100644
> index 000..e48e508
> --- /dev/null
> +++ b/doc/device-tree-bindings/exynos/emmc-reset.txt
> @@ -0,0 +1,15 @@
> +* Samsung eMMC reset
> +
> +Some exynos boards require special handling of SD4_nRESET_OUT line for eMMC
> +memory to perform complete reboot.
> +
> +Required properties:
> +- compatible: should be "samsung,emmc-reset"
> +- reset-gpio: gpio chip for eMMC reset.
> +
> +Example:
> +
> +emmc-reset {
> +compatible = "samsung,emmc-reset";
> +reset-gpio = <&gpk1 2 0>;
> +};
> --
> 1.9.1
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND] usb: gadget: pxa25x_udc: fix use-before-initialized bug
Fix use-before-initialized bug in pxa25x_udc driver.
Function usb_gadget_register_driver calls udc_disable,
and udc_disable calls pullup_off that uses dev->mach->udc_command.
But dev->mach is initialized in usb_gadget_register_driver after
calling udc_disable. This patch fixes the order of initialization.
Signed-off-by: Alex Sadovsky
---
I'm resending the patch with fixed 'Signed-off-by:' and 'From:' fields.
There are no changes in patch contents.
drivers/usb/gadget/pxa25x_udc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/pxa25x_udc.c b/drivers/usb/gadget/pxa25x_udc.c
index 8945c5b..d4460b2 100644
--- a/drivers/usb/gadget/pxa25x_udc.c
+++ b/drivers/usb/gadget/pxa25x_udc.c
@@ -1950,11 +1950,11 @@ int usb_gadget_register_driver(struct usb_gadget_driver
*driver)
dev->watchdog.period = 5000 * CONFIG_SYS_HZ / 100; /* 5 ms */
dev->watchdog.function = udc_watchdog;
+ dev->mach = &mach_info;
+
udc_disable(dev);
udc_reinit(dev);
- dev->mach = &mach_info;
-
dev->gadget.name = "pxa2xx_udc";
retval = driver->bind(&dev->gadget);
if (retval) {
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Fix repeated USB scans problems
Hi, On 08-01-15 18:36, Marek Vasut wrote: On Thursday, January 08, 2015 at 06:23:55 PM, Hans de Goede wrote: Hi, On 08-01-15 18:06, Marek Vasut wrote: On Thursday, January 08, 2015 at 05:16:53 PM, Stephen Warren wrote: On 01/08/2015 01:34 AM, Hans de Goede wrote: Hi, Hi! On 08-01-15 01:19, Stephen Warren wrote: On 01/07/2015 04:35 PM, Marek Vasut wrote: On Tuesday, January 06, 2015 at 06:02:57 PM, Stephen Warren wrote: Should we rename "usb reset" to "usb restart"? No, let's not mess with the UI any more than we already did. Well, it might not be such a bad idea if the semantics are changing, to give people a heads-up? Only the semantics of "usb start" are changing, and you are suggesting renaming "usb reset" which remains unchanged ... Yes, that's true. So I suppose we should indeed not rename anything. OK, let's go with this approach now. So we are all in agreement, good, so through who's tree are these 2 patches going to go upstream ? Note I can take them upstream through the sunxi tree, but the usb tree seems better to me ... I can pick them, shall I pick them as they are ? Yes, AFAIK there were no requests for changes. Are they for -next or current ? They are intended for -next, the double usb scan when using a usb keyboard *and* booting from usb is a nuisance, but not fatal, and very few people actually use the combo, so given that current is about to be released in a couple of days lets play it safe :) Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Fix repeated USB scans problems
On Thursday, January 08, 2015 at 06:23:55 PM, Hans de Goede wrote: > Hi, > > On 08-01-15 18:06, Marek Vasut wrote: > > On Thursday, January 08, 2015 at 05:16:53 PM, Stephen Warren wrote: > >> On 01/08/2015 01:34 AM, Hans de Goede wrote: > >>> Hi, > > > > Hi! > > > >>> On 08-01-15 01:19, Stephen Warren wrote: > On 01/07/2015 04:35 PM, Marek Vasut wrote: > > On Tuesday, January 06, 2015 at 06:02:57 PM, Stephen Warren wrote: > >>> > >>> > >> Should we rename "usb reset" to "usb restart"? > > > > No, let's not mess with the UI any more than we already did. > > Well, it might not be such a bad idea if the semantics are changing, > to give people a heads-up? > >>> > >>> Only the semantics of "usb start" are changing, and you are suggesting > >>> renaming "usb reset" which remains unchanged ... > >> > >> Yes, that's true. So I suppose we should indeed not rename anything. > > > > OK, let's go with this approach now. > > So we are all in agreement, good, so through who's tree are these 2 > patches going to go upstream ? Note I can take them upstream through > the sunxi tree, but the usb tree seems better to me ... I can pick them, shall I pick them as they are ? Are they for -next or current ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: vf610: fix boot from SD-card
On 8 Jan 2015, ste...@agner.ch wrote:
> Boot from SD-card (and probably also from NAND) was broken since
> commit d6d07a9bec ("arm: vf610: add NAND support for vf610twr").
> It looks like the increased size of U-Boot lead to a situation
> where the boot ROM overwrote its own stack/heap while loading
> U-Boot from the SD-card to the SRAM. However, U-Boot worked fine
> when loaded through USB serial loader directly into SRAM. It
> looks like loading from SD-card uses other stack/heap location
> then the serial loader (or maybe no stack or heap at all).
> This fix moves U-Boot to gfxRAM, which is 512kB in size and is not
> used by the boot ROM nor the SD-card loader of it.
>
> Signed-off-by: Stefan Agner
> ---
> We use U-Boot from gfxRAM on Vybrid since quite a while for the
> Colibri VF50/VF61 modules in our downstream U-Boot branch. Hence
> this is quite well tested.
>
> Just today I discovered that this is broken on the Tower module.
> Back then, when I made the offending change, I only tested on the
> Tower board using the serial loader, since I thought the behaviour
> should be exactly the same. But now, I know better... :-)
>
> If still possible, it would be great to get this into v2015.01...
>
> include/configs/vf610twr.h | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
> index 6fd0b17..bd79e81 100644
> --- a/include/configs/vf610twr.h
> +++ b/include/configs/vf610twr.h
> @@ -125,7 +125,10 @@
> #define CONFIG_BOOTDELAY 3
>
> #define CONFIG_LOADADDR 0x8200
> -#define CONFIG_SYS_TEXT_BASE 0x3f008000
> +
> +/* We boot from the gfxRAM area of the OCRAM. */
> +#define CONFIG_SYS_TEXT_BASE 0x3f408000
> +#define CONFIG_BOARD_SIZE_LIMIT 524288
>
> #define CONFIG_EXTRA_ENV_SETTINGS \
> "script=boot.scr\0" \
Acked-by: Bill Pringlemeir
See also:
http://lists.denx.de/pipermail/u-boot/2014-December/197641.html
It seems since v2014.04 u-boot on the Vybrid Tower SD card has not
booted. Most users will probably boot this way.
https://community.freescale.com/docs/DOC-95248
Thanks,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Fix repeated USB scans problems
Hi, On 08-01-15 18:06, Marek Vasut wrote: On Thursday, January 08, 2015 at 05:16:53 PM, Stephen Warren wrote: On 01/08/2015 01:34 AM, Hans de Goede wrote: Hi, Hi! On 08-01-15 01:19, Stephen Warren wrote: On 01/07/2015 04:35 PM, Marek Vasut wrote: On Tuesday, January 06, 2015 at 06:02:57 PM, Stephen Warren wrote: Should we rename "usb reset" to "usb restart"? No, let's not mess with the UI any more than we already did. Well, it might not be such a bad idea if the semantics are changing, to give people a heads-up? Only the semantics of "usb start" are changing, and you are suggesting renaming "usb reset" which remains unchanged ... Yes, that's true. So I suppose we should indeed not rename anything. OK, let's go with this approach now. So we are all in agreement, good, so through who's tree are these 2 patches going to go upstream ? Note I can take them upstream through the sunxi tree, but the usb tree seems better to me ... Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/17] videomodes: Add support for refresh and pclk_khz to video_get_params()
On Wed, 24 Dec 2014 20:06:13 +0100 Hans de Goede wrote: > Add support to video_get_params() for setting the new refresh and pixclock_khz > struct ctfb_res_modes members. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: vf610: fix boot from SD-card
Boot from SD-card (and probably also from NAND) was broken since
commit d6d07a9bec ("arm: vf610: add NAND support for vf610twr").
It looks like the increased size of U-Boot lead to a situation
where the boot ROM overwrote its own stack/heap while loading
U-Boot from the SD-card to the SRAM. However, U-Boot worked fine
when loaded through USB serial loader directly into SRAM. It
looks like loading from SD-card uses other stack/heap location
then the serial loader (or maybe no stack or heap at all).
This fix moves U-Boot to gfxRAM, which is 512kB in size and is not
used by the boot ROM nor the SD-card loader of it.
Signed-off-by: Stefan Agner
---
We use U-Boot from gfxRAM on Vybrid since quite a while for the
Colibri VF50/VF61 modules in our downstream U-Boot branch. Hence
this is quite well tested.
Just today I discovered that this is broken on the Tower module.
Back then, when I made the offending change, I only tested on the
Tower board using the serial loader, since I thought the behaviour
should be exactly the same. But now, I know better... :-)
If still possible, it would be great to get this into v2015.01...
include/configs/vf610twr.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
index 6fd0b17..bd79e81 100644
--- a/include/configs/vf610twr.h
+++ b/include/configs/vf610twr.h
@@ -125,7 +125,10 @@
#define CONFIG_BOOTDELAY 3
#define CONFIG_LOADADDR0x8200
-#define CONFIG_SYS_TEXT_BASE 0x3f008000
+
+/* We boot from the gfxRAM area of the OCRAM. */
+#define CONFIG_SYS_TEXT_BASE 0x3f408000
+#define CONFIG_BOARD_SIZE_LIMIT524288
#define CONFIG_EXTRA_ENV_SETTINGS \
"script=boot.scr\0" \
--
2.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] sunxi: video: Set input sync enable
On Sat, 20 Dec 2014 15:42:05 +0100 Hans de Goede wrote: > Add a write to the "unknown" (*) register to enable auto input sync, when > initially adding sunxi hdmi output support this magic write from the android > kernel code was missed, causing lcdc -> hdmi encoder sync problems. > > With this write added, we can drop the modesetting retries and the extra > delays added to work around these sync problems. > > *) "unknown" is the actual name of this register in the android kernel sources > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] sunxi: video: Give hotplug-detect (hpd) signal some time to show up
On Sat, 20 Dec 2014 15:42:04 +0100 Hans de Goede wrote: > When using a hdmi powered hdmi to vga dongle, and cold booting a sunxi > device, the hpd detect code would not see the dongle (until a warm reboot), > because the dongle needs some time to boot. > > Testing has shown that this dongle needs 213ms to respond on a cold boot, > so wait up to 300ms for a hpd signal to show up before giving up. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Fix repeated USB scans problems
On Thursday, January 08, 2015 at 05:16:53 PM, Stephen Warren wrote: > On 01/08/2015 01:34 AM, Hans de Goede wrote: > > Hi, Hi! > > On 08-01-15 01:19, Stephen Warren wrote: > >> On 01/07/2015 04:35 PM, Marek Vasut wrote: > >>> On Tuesday, January 06, 2015 at 06:02:57 PM, Stephen Warren wrote: > > > > > Should we rename "usb reset" to "usb restart"? > >>> > >>> No, let's not mess with the UI any more than we already did. > >> > >> Well, it might not be such a bad idea if the semantics are changing, > >> to give people a heads-up? > > > > Only the semantics of "usb start" are changing, and you are suggesting > > renaming "usb reset" which remains unchanged ... > > Yes, that's true. So I suppose we should indeed not rename anything. OK, let's go with this approach now. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: gadget: pxa25x_udc: fix use-before-initialized bug
On Thursday, January 08, 2015 at 09:38:45 AM, Nable wrote: > Hi! Hi! > > Can you please fix From: and Signed-off-by: fields > > Oh, it looks like I have to accept this requirement. Ok, I'll fix it. > Should I also change tag in subject to '[PATCH v2]' in a fixed patch? > > Thank you for kind answer! You can use [PATCH RESEND], which is probably much clearer in expressing the intent. You might add a short note just before the diffstat saying that you only updated the SoB line and author to match the real deal, but didn't change the patch contents. You can read [1] for the finer points of patch submission process, but TL;DR it's pretty much the same as Linux ;-) [1] http://www.denx.de/wiki/U-Boot/Patches#General_Patch_Submission_Rules Thank you! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] sunxi: video: When using edid use CEA681 extension blocks to select hdmi output
On Sat, 20 Dec 2014 15:42:03 +0100 Hans de Goede wrote: > When using edid use CEA681 edid extension blocks to select between dvi and > hdmi output formats, so that u-boot will automatically do the right thing. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] sunxi: video: Add sunxi_hdmi_edid_get_block helper function
On Sat, 20 Dec 2014 15:42:02 +0100 Hans de Goede wrote: > Add a sunxi_hdmi_edid_get_block helper function, this is a preparation patch > for adding support for parsing EDID extension blocks. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] sunxi: video: Add hdmi support
On Sat, 20 Dec 2014 15:42:01 +0100 Hans de Goede wrote: > So far we've been programming the hdmi-encoder to send out dvi data over the > hdmi connector. This works well for most devices, including hdmi devices, but > not all devices accept dvi data on a hdmi input. > > Add support for sending proper hdmi data over the hdmi output found on most > sunxi boards. This can be turned on by adding by adding monitor=hdmi as option "by adding" is duplicated here, please drop when applying. > to the video-mode env. variable. > > A follow up patch will determine wether to send dvi or hdmi automatically when > EDID is used. s/wether/whether/ > Signed-off-by: Hans de Goede Otherwise Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] edid: Add struct and defines for cea681 extension blocks
On Sat, 20 Dec 2014 15:42:00 +0100 Hans de Goede wrote: > Add a struct describing the (fixed) bits of cea681 edid extension blocks, > and defines for accessing various bitfields. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] edid: Add struct and defines for cea681 extension blocks
On Sat, 20 Dec 2014 15:42:00 +0100 Hans de Goede wrote: > Add a struct describing the (fixed) bits of cea681 edid extension blocks, > and defines for accessing various bitfields. > > Signed-off-by: Hans de Goede ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] sunxi: video: Add DDC & EDID support
On Fri, 19 Dec 2014 18:10:41 +0100 Hans de Goede wrote: > Add DDC & EDID support and use it to automatically select the native mode of > the attached monitor. This can be disabled by adding edid=0 as option > to the video-mode env. variable. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Fix repeated USB scans problems
On 01/08/2015 01:34 AM, Hans de Goede wrote: Hi, On 08-01-15 01:19, Stephen Warren wrote: On 01/07/2015 04:35 PM, Marek Vasut wrote: On Tuesday, January 06, 2015 at 06:02:57 PM, Stephen Warren wrote: Should we rename "usb reset" to "usb restart"? No, let's not mess with the UI any more than we already did. Well, it might not be such a bad idea if the semantics are changing, to give people a heads-up? Only the semantics of "usb start" are changing, and you are suggesting renaming "usb reset" which remains unchanged ... Yes, that's true. So I suppose we should indeed not rename anything. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/11] sunxi: video: Add hpd option
On Fri, 19 Dec 2014 18:10:40 +0100 Hans de Goede wrote: > Allow the user to specify hpd=0 as option in the video-mode env. variable, > if hpd is set to 0 then the hdmi output will be brought up even if no cable > is connected. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/11] sunxi: video: Add support for video-mode environment variable
On Fri, 19 Dec 2014 18:10:39 +0100 Hans de Goede wrote: > Add support for the standard video-mode environment variable using the > videomodes.c video_get_ctfb_res_modes() helper function. > > This will allow users to specify the resolution e.g. : > > setenv video-mode sunxi:video-mode=1280x1024-24@60 > saveenv > > Also make the reserved fb mem slightly larger to allow 1920x1200 to work. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/11] sunxi: video: Use video-mode/-timing from videomodes
On Fri, 19 Dec 2014 18:10:38 +0100 Hans de Goede wrote: > Switch from fb_videomode to ctfb_res_modes and use the predefined videotimings > from videomodes.c, rather then defining our own. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/11] edid: Add an edid_check_checksum() helper function
On Fri, 19 Dec 2014 18:10:37 +0100 Hans de Goede wrote: > Add a helper function to check the checksum of an EDID data block. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/11] videomodes: Add video_edid_dtd_to_ctfb_res_modes helper function
On Fri, 19 Dec 2014 18:10:36 +0100 Hans de Goede wrote: > Add a video_edid_dtd_to_ctfb_res_modes helper function to convert an EDID > detailed timing to a struct ctfb_res_modes. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/11] videomodes: Add helper functions to parse video-mode env-var extra options
On Fri, 19 Dec 2014 18:10:35 +0100
Hans de Goede wrote:
> Add 2 helper functions to get strings, reps. ints from the options value
> returned by video_get_video_mode() / video_get_ctfb_res_modes().
>
> Signed-off-by: Hans de Goede
before applying please fix these checkpatch warnings:
WARNING: space prohibited between function name and open parenthesis '('
#32: FILE: drivers/video/videomodes.c:116:
+video_get_param_len (const char *start, char sep)
WARNING: space prohibited between function name and open parenthesis '('
#58: FILE: drivers/video/videomodes.c:334:
+ while (p && (i = video_get_param_len (p, ',')) != 0) {
WARNING: space prohibited between function name and open parenthesis '('
#88: FILE: drivers/video/videomodes.c:364:
+ while (p && (i = video_get_param_len (p, ',')) != 0) {
total: 0 errors, 3 warnings, 0 checks, 77 lines checked
With these warnings fixed,
Acked-by: Anatolij Gustschin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx25: Fix boot hang by avoiding vector relocation
> On Tue, Jan 06, 2015 at 01:06:48PM -0200, Fabio Estevam wrote:
>> From: Fabio Estevam
>>
>> Since commit 3ff46cc42b9d73d0 ("arm: relocate the exception vectors")
>> mx25pdk hangs like this:
>>
>> CPU: Freescale i.MX25 rev1.2 at 399 MHz
>> Reset cause: WDOG
>> Board: MX25PDK
>> I2C: ready
>> DRAM: 64 MiB
>> (hangs)
>>
>> Add a specific relocate_vectors macro that skips the vector
>> relocation, as the i.MX25 SoC does not provide RAM at the high
>> vectors address (0x), and (0x) maps to ROM.
>>
>> This allows mx25 to boot again.
>>
>> Signed-off-by: Fabio Estevam
On 8 Jan 2015, tr...@ti.com wrote:
> I'd like to pull this in for the release. I'd also really like
> someone else to ack or otherwise comment on this (and why this is more
> right than not just relocating the vectors as v1 did, I see both boot
> to a U-Boot prompt but shouldn't we do a bit more testing to confirm
> that we don't need to relocate these exception vectors or have we now
> introduced some subtle breakage (or perhaps not so subtle once you hit
> it) in these cases? Thanks!
Acked-By: Bill Pringlemeir
The addresses in v1 of the patch are for the imx27. The will do nothing
for the imx25. On the imx25, the address 0x0 is ROM and will BUS error
on a write (default without any patch). The address 0x is
mapped to a WEIM peripheral (external Addr+Data w chip select) and
writes there will not BUS error (so v1 patch works). However, it is
misleading as the real 'hook' vectors are located in IRAM (0x78xx);
it is very similar in concept to imx27. It is better just to provide a
stub that does nothing than misleading people to think they are hooked.
The HAB code on the iMX25 ROM has some vectors installed so that any
errors will reset or go to serial boot mode. This is what this platform
has done all along. The most correct way would be to hook the vectors,
but the hook addresses are only in an NDA doc and would require some
testing, etc. because even that document is not 100% clear.
Fwiw,
Bill Pringlemeir.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support
Hi Bin, On 7 January 2015 at 23:18, Bin Meng wrote: > Hi Simon, > > On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass wrote: >> NOT TO APPLY >> >> This shows how to enable video for the glacier board, as an example of the >> emulator working on a VESA-compliant graphics card. >> >> Signed-off-by: Simon Glass >> --- >> >> include/configs/canyonlands.h | 31 +++ >> 1 file changed, 31 insertions(+) >> >> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h >> index 7a1499d..c55e076 100644 >> --- a/include/configs/canyonlands.h >> +++ b/include/configs/canyonlands.h >> @@ -133,6 +133,9 @@ >> #define CONFIG_SYS_NOR_CS 0 /* NOR chip connected to CSx >> */ >> #define CONFIG_SYS_NAND_CS 3 /* NAND chip connected to >> CSx */ >> >> +#define CONFIG_CONSOLE_MUX >> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV >> + >> /*--- >> * FLASH related >> *--*/ >> @@ -359,6 +362,15 @@ >> "ramdisk_addr=fc20\0" \ >> "pciconfighost=1\0" \ >> "pcie_mode=RP:RP\0" \ >> + "eth1addr=00:01:ec:00:f4:9d\0" \ >> + "eth2addr=00:01:ec:00:f4:9e\0" \ >> + "eth3addr=00:01:ec:00:f4:9f\0" \ >> + "ethact=ppc_4xx_eth0\0" \ >> + "ethaddr=00:01:ec:00:f4:9c\0" \ >> + "stderr=serial\0" \ >> + "stdin=serial\0" \ >> + "stdout=serial,vga\0" \ >> + "autoload=n\0" \ >> "" >> #else /* defined(CONFIG_ARCHES) */ >> #define CONFIG_EXTRA_ENV_SETTINGS \ >> @@ -675,4 +687,23 @@ >> } >> #endif >> >> +#define CONFIG_VIDEO >> + >> +#ifdef CONFIG_VIDEO >> +#define CONFIG_BIOSEMU /* x86 bios emulator for vga bios */ >> +#define CONFIG_VIDEO_VESA >> +#define VIDEO_IO_OFFSET0xd800 >> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS VIDEO_IO_OFFSET >> +#define CONFIG_VIDEO_SW_CURSOR >> +#define CONFIG_VIDEO_LOGO >> +#define CONFIG_CFB_CONSOLE >> +#define CONFIG_SPLASH_SCREEN >> +#define CONFIG_VGA_AS_SINGLE_DEVICE >> +#define CONFIG_CMD_BMP >> +#endif >> + >> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE >> +#define CONFIG_FRAMEBUFFER_VESA_MODE 0x114 >> +#define CONFIG_CMD_TFTPPUT >> + >> #endif /* __CONFIG_H */ >> -- > > Could you also post the codes that actually run the vga bios on ppc > target? I may find another non-x86 board to test. It is all there - I am using the existing support. If you see pci_run_vga_bios() it calls biosemu_run() in the emulation case. Re your other question I was looking for the VGA enable bit, as I remembered it from years ago. It doesn't seem to be needed for that platforms I have tested. But if it is generally needed we should add it. For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is called. I wonder if you haven't enabled the ROM BAR? I initially got the same result as you. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] videomodes: Add video_get_ctfb_res_modes helper function
On Fri, 19 Dec 2014 18:10:34 +0100 Hans de Goede wrote: > Add a video_get_ctfb_res_modes() helper function, which uses > video_get_video_mode() to parse the 'video-mode' environment variable and then > looks up the matching mode in res_mode_init and returns the matching mode. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx25: Fix boot hang by avoiding vector relocation
On Tue, Jan 06, 2015 at 01:06:48PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Since commit 3ff46cc42b9d73d0 ("arm: relocate the exception vectors") mx25pdk
> hangs like this:
>
> CPU: Freescale i.MX25 rev1.2 at 399 MHz
> Reset cause: WDOG
> Board: MX25PDK
> I2C: ready
> DRAM: 64 MiB
> (hangs)
>
> Add a specific relocate_vectors macro that skips the vector relocation, as
> the
> i.MX25 SoC does not provide RAM at the high vectors address (0x), and
> (0x) maps to ROM.
>
> This allows mx25 to boot again.
>
> Signed-off-by: Fabio Estevam
I'd like to pull this in for the release. I'd also really like someone
else to ack or otherwise comment on this (and why this is more right
than not just relocating the vectors as v1 did, I see both boot to a
U-Boot prompt but shouldn't we do a bit more testing to confirm that we
don't need to relocate these exception vectors or have we now introduced
some subtle breakage (or perhaps not so subtle once you hit it) in these
cases? 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 03/11] videomodes: Add a bunch of high res modes
On Fri, 19 Dec 2014 18:10:33 +0100 Hans de Goede wrote: > Add modes useful for hd-tvs and modern monitors. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/11] videomodes: Add (vesa) standard timings
On Fri, 19 Dec 2014 18:10:32 +0100 Hans de Goede wrote: > The timings for the modes defined in videomodes.c differ (significantly) > from vesa standard timings for these modes. > > This commit adds a version with the proper std timings for these modes, > since I do not want to cause regressions, boards which want to use the > standard > timings need to define CONFIG_VIDEO_STD_TIMINGS to get the new correct > timings. > > Since there is no std timing for 960x720 this commit uses the timing used > by the nvidia video drivers for 960x720, which uses a standard pixelclock > of 74.25 MHz rather then the weird 76.335... clock used by the old modes. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] videomodes: Add pixelclock_khz and refresh fields to ctfb_res_modes
On Fri, 19 Dec 2014 18:10:31 +0100 Hans de Goede wrote: > Add pixelclock_khz and refresh fields to ctfb_res_modes: > > 1) pixelclocks are usually referred to in hz, not picoseconds, and e.g > pll-s are also typically programmed in hz, not ps. Converting between the > 2 leads to rounding differences, add a pixelclock_khz field to directly > store the *exact* pixelclock for a mode, so that drivers do not need to > resort to rounding tricks to try and guess the exact pixelclock; > > 2) The video-mode environment variable, as parsed by video_get_video_mode > also contains the vertical refresh rate, add a refresh field, so that > the refresh-rate can be matched when parsing the video-mode environment > variable. > > Signed-off-by: Hans de Goede Acked-by: Anatolij Gustschin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/18] exynos5: config: prepare for dm i2c support
Hi, On 08/01/15 20:33, Przemyslaw Marczak wrote: > This commit allows for test i2c drivers with new i2c api > on Exynos5xxx based boards. > > The S3C24X0 I2C driver supports driver model I2C api, > but i2c peripherials drivers on exynos5 boards doesn't. > So this commit allows for test ported driver before switch > the Exynos5 boards to DM I2C at all. > > Signed-off-by: Przemyslaw Marczak > Cc: Akshay Saraswat > Cc: Simon Glass > Cc: Minkyu Kang > --- > include/configs/exynos5-common.h | 29 ++--- > 1 file changed, 18 insertions(+), 11 deletions(-) > > diff --git a/include/configs/exynos5-common.h > b/include/configs/exynos5-common.h > index ad63f3c..b7af8a5 100644 > --- a/include/configs/exynos5-common.h > +++ b/include/configs/exynos5-common.h > @@ -54,13 +54,6 @@ > #define CONFIG_CMD_DTT > #define CONFIG_TMU_CMD_DTT > > -/* TPM */ > -#define CONFIG_TPM > -#define CONFIG_CMD_TPM > -#define CONFIG_TPM_TIS_I2C > -#define CONFIG_TPM_TIS_I2C_BUS_NUMBER3 > -#define CONFIG_TPM_TIS_I2C_SLAVE_ADDR0x20 > - > /* MMC SPL */ > #define COPY_BL2_FNPTR_ADDR 0x02020030 > #define CONFIG_SUPPORT_EMMC_BOOT > @@ -126,15 +119,29 @@ > #define SPI_FLASH_UBOOT_POS (CONFIG_SEC_FW_SIZE + CONFIG_BL1_SIZE) > > /* I2C */ > -#define CONFIG_SYS_I2C_INIT_BOARD > -#define CONFIG_SYS_I2C > +#if 0 /* For test */ > +#define CONFIG_DM_I2C > +#endif please remove test code > #define CONFIG_CMD_I2C > -#define CONFIG_SYS_I2C_S3C24X0_SPEED 10 /* 100 Kbps */ > #define CONFIG_SYS_I2C_S3C24X0 > -#define CONFIG_I2C_MULTI_BUS > +#define CONFIG_SYS_I2C_S3C24X0_SPEED 10 /* 100 Kbps */ > #define CONFIG_SYS_I2C_S3C24X0_SLAVE0x0 > +#ifndef CONFIG_DM_I2C > +#define CONFIG_SYS_I2C_INIT_BOARD > +#define CONFIG_SYS_I2C > +#define CONFIG_I2C_MULTI_BUS > +#endif /* ifndef CONFIG_DM_I2C */ > #define CONFIG_I2C_EDID > > +/* TPM */ > +#ifndef CONFIG_DM_I2C > +#define CONFIG_TPM > +#define CONFIG_CMD_TPM > +#define CONFIG_TPM_TIS_I2C > +#define CONFIG_TPM_TIS_I2C_BUS_NUMBER3 > +#define CONFIG_TPM_TIS_I2C_SLAVE_ADDR0x20 > +#endif > + > /* SPI */ > #ifdef CONFIG_SPI_FLASH > #define CONFIG_EXYNOS_SPI > Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 18/18] trats2: config: disable i2c peripherals if testing dm i2c
On 08/01/15 20:33, Przemyslaw Marczak wrote: > Most i2c peripherals for this board doesn't > support new i2c api. So CONFIG_DM_I2C on this > board can be enabled for test only. The i2c command > works fine with it. > This is the first step before adding > support to the new power framework soon. > > Signed-off-by: Przemyslaw Marczak > Cc: Lukasz Majewski > Cc: Jaehoon Chung > Cc: Simon Glass > Cc: Minkyu Kang > --- > include/configs/trats2.h | 17 + > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/include/configs/trats2.h b/include/configs/trats2.h > index 42481ab..8b099dd 100644 > --- a/include/configs/trats2.h > +++ b/include/configs/trats2.h > @@ -159,15 +159,18 @@ > #define CONFIG_RANDOM_UUID > > /* I2C */ > -#include > - > +#if 0 /* For test */ > +#define CONFIG_DM_I2C > +#endif please remove test code. > #define CONFIG_CMD_I2C > - > -#define CONFIG_SYS_I2C > #define CONFIG_SYS_I2C_S3C24X0 > #define CONFIG_SYS_I2C_S3C24X0_SPEED 10 > #define CONFIG_SYS_I2C_S3C24X0_SLAVE 0 > + > +#ifndef CONFIG_DM_I2C > +#define CONFIG_SYS_I2C > #define CONFIG_MAX_I2C_NUM 8 > + > #define CONFIG_SYS_I2C_SOFT > #define CONFIG_SYS_I2C_SOFT_SPEED5 > #define CONFIG_SYS_I2C_SOFT_SLAVE0x00 > @@ -177,6 +180,8 @@ > #define CONFIG_SOFT_I2C_READ_REPEATED_START > #define CONFIG_SYS_I2C_INIT_BOARD > > +#include > + > #ifndef __ASSEMBLY__ > int get_soft_i2c_scl_pin(void); > int get_soft_i2c_sda_pin(void); > @@ -192,6 +197,7 @@ int get_soft_i2c_sda_pin(void); > #define CONFIG_POWER_MUIC_MAX77693 > #define CONFIG_POWER_FG_MAX77693 > #define CONFIG_POWER_BATTERY_TRATS2 > +#endif /* ifndef CONFIG_DM_I2C */ > > /* Security subsystem - enable hw_rand() */ > #define CONFIG_EXYNOS_ACE_SHA > @@ -203,11 +209,13 @@ int get_soft_i2c_sda_pin(void); > #define CONFIG_MISC_INIT_R > > /* Download menu - Samsung common */ > +#ifndef CONFIG_DM_I2C > #define CONFIG_LCD_MENU > #define CONFIG_LCD_MENU_BOARD > > /* Download menu - definitions for check keys */ > #ifndef __ASSEMBLY__ > +#include > #include > > #define KEY_PWR_PMIC_NAME"MAX77686_PMIC" > @@ -219,6 +227,7 @@ int get_soft_i2c_sda_pin(void); > #define KEY_VOL_UP_GPIO EXYNOS4X12_GPIO_X22 > #define KEY_VOL_DOWN_GPIOEXYNOS4X12_GPIO_X33 > #endif /* __ASSEMBLY__ */ > +#endif > > /* LCD console */ > #define LCD_BPP LCD_COLOR16 > Thanks, Minkyu Kang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-uniphier
Hi Tom, Please pull some Panasonic SoC specific updates. The following changes since commit 40ad4c4b1fea2497bc019ee82163b76d4b076730: Kconfig: move EXPERT option under "General setup" menu (2015-01-07 14:48:47 -0500) are available in the git repository at: git://git.denx.de/u-boot-uniphier.git master for you to fetch changes up to b4ad44baab713af371b1113dd63dd222ba73ba13: ARM: UniPhier: add UART initialization routine for low-level debug (2015-01-08 23:01:56 +0900) Masahiro Yamada (3): ARM: UniPhier: fix SRAM size on support card ARM: UniPhier: enable output of system bus ARM: UniPhier: add UART initialization routine for low-level debug arch/arm/cpu/armv7/uniphier/lowlevel_init.S | 4 arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile | 1 + arch/arm/cpu/armv7/uniphier/ph1-ld4/lowlevel_debug.S | 29 + arch/arm/cpu/armv7/uniphier/ph1-ld4/sbc_init.c| 7 +++ arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile | 1 + arch/arm/cpu/armv7/uniphier/ph1-pro4/lowlevel_debug.S | 39 +++ arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile | 1 + arch/arm/cpu/armv7/uniphier/ph1-sld8/lowlevel_debug.S | 29 + arch/arm/cpu/armv7/uniphier/ph1-sld8/sbc_init.c | 7 +++ arch/arm/cpu/armv7/uniphier/support_card.c| 6 +++--- arch/arm/include/asm/arch-uniphier/debug-uart.S | 24 arch/arm/include/asm/arch-uniphier/sbc-regs.h | 1 + 12 files changed, 146 insertions(+), 3 deletions(-) create mode 100644 arch/arm/cpu/armv7/uniphier/ph1-ld4/lowlevel_debug.S create mode 100644 arch/arm/cpu/armv7/uniphier/ph1-pro4/lowlevel_debug.S create mode 100644 arch/arm/cpu/armv7/uniphier/ph1-sld8/lowlevel_debug.S create mode 100644 arch/arm/include/asm/arch-uniphier/debug-uart.S -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: UniPhier: add UART initialization routine for low-level debug
2015-01-06 14:28 GMT+09:00 Masahiro Yamada : > The low-level debugging functions are useful to debug the early boot > stage where the full UART driver is not available. > > UniPhier SoCs need to initialize the UART port 0 to use this feature. > The initialization routine is called at the very entry of the > lowlevel_init(). > > Signed-off-by: Masahiro Yamada Applied to u-boot-uniphier/master -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: UniPhier: enable output of system bus
2015-01-06 14:20 GMT+09:00 Masahiro Yamada : > For NAND boot on PH1-LD4, PH1-sLD8, and some other SoCs, > the output of the system bus is disabled by default. > It must be enabled by software to have access to the system bus. > > Signed-off-by: Masahiro Yamada Applied to u-boot-uniphier/master -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: UniPhier: fix SRAM size on support card
2015-01-06 14:18 GMT+09:00 Masahiro Yamada : > The max size of available memories on slot0 and slot1 is 32MB because > - EA[25] signal is not output on the save-pin mode which is >used PH1-LD4 or later SoCs. > - EA[25] signal is not connected by the limitation (or bug?) of >the PLD logic of DCC support card. > > Signed-off-by: Masahiro Yamada Applied to u-boot-uniphier/master -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Nokia RX-51: Do not call secure PPA routine on non secure devices
On Thu 2015-01-08 10:11:40, Pali Rohár wrote: > Since commit 41623c91b09a0c865fab41acdaff30f060f29ad6 u-boot running in qemu > is > crashing in function do_omap3_emu_romcode_call(). RX-51 board uses this > function > for Cortex-A8 errata 430973 workaround (Set IBE bit in ACR) which is needed > only > on real secure device and not in qemu. > > This board patch just disable calling secure PPA routine on non secure > devices. > Qemu implements GP device and with this patch u-boot is working in qemu again. > > Signed-off-by: Pali Rohár Acked-by: Pavel Machek > --- > board/nokia/rx51/rx51.c |6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c > index b6b8ad6..08fcaf2 100644 > --- a/board/nokia/rx51/rx51.c > +++ b/board/nokia/rx51/rx51.c > @@ -422,8 +422,12 @@ int misc_init_r(void) > /* >* Cortex-A8(r1p0..r1p2) errata 430973 workaround >* Set IBE bit in Auxiliary Control Register > + * > + * Call this routine only on real secure device > + * Qemu does not implement secure PPA and crash >*/ > - omap3_update_aux_cr_secure_rx51(1 << 6, 0); > + if (get_device_type() == HS_DEVICE) > + omap3_update_aux_cr_secure_rx51(1 << 6, 0); > > return 0; > } -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] pmic:pfuze implement pmic_mode_init
This patch is to implement pmic_mode_init function, and add prototype
in header file.
This function is to set switching mode for pmic buck regulators to
improve system efficiency.
Mode:
OFF: The regulator is switched off and the output voltage is discharged.
PFM: In this mode, the regulator is always in PFM mode, which
is useful at light loads for optimized efficiency.
PWM: In this mode, the regulator is always in PWM mode operation
regardless of load conditions.
APS: In this mode, the regulator moves automatically between
pulse skipping mode and PWM mode depending on load conditions.
Signed-off-by: Peng Fan
---
board/freescale/common/pfuze.c | 36
board/freescale/common/pfuze.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/board/freescale/common/pfuze.c b/board/freescale/common/pfuze.c
index 2cd1794..74df69c 100644
--- a/board/freescale/common/pfuze.c
+++ b/board/freescale/common/pfuze.c
@@ -8,6 +8,42 @@
#include
#include
+int pfuze_mode_init(struct pmic *p, u32 mode)
+{
+ unsigned char offset, i, switch_num;
+ u32 id, ret;
+
+ pmic_reg_read(p, PFUZE100_DEVICEID, &id);
+ id = id & 0xf;
+
+ if (id == 0) {
+ switch_num = 6;
+ offset = PFUZE100_SW1CMODE;
+ } else if (id == 1) {
+ switch_num = 4;
+ offset = PFUZE100_SW2MODE;
+ } else {
+ printf("Not supported, id=%d\n", id);
+ return -1;
+ }
+
+ ret = pmic_reg_write(p, PFUZE100_SW1ABMODE, mode);
+ if (ret < 0) {
+ printf("Set SW1AB mode error!\n");
+ return ret;
+ }
+
+ for (i = 0; i < switch_num - 1; i++) {
+ ret = pmic_reg_write(p, offset + i * 7, mode);
+ if (ret < 0) {
+ printf("Set switch%x mode error!\n", offset + i * 7);
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
struct pmic *pfuze_common_init(unsigned char i2cbus)
{
struct pmic *p;
diff --git a/board/freescale/common/pfuze.h b/board/freescale/common/pfuze.h
index 7a4126c..53cfc99 100644
--- a/board/freescale/common/pfuze.h
+++ b/board/freescale/common/pfuze.h
@@ -8,5 +8,6 @@
#define __PFUZE_BOARD_HELPER__
struct pmic *pfuze_common_init(unsigned char i2cbus);
+int pfuze_mode_init(struct pmic *p, u32 mode);
#endif
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] pmic:pfuze support buck regulator mode switch
This patch set is to support buck regulator can working in different switching modes. To improve system efficiency the buck regulators can operate in different switching modes. patch 1/3 is to add related bit definitions and registers. patch 2/3 is to implement the switching mode init function. patch 3/3 is to add related mode init function in board code. mx6slevk board is not included in this patch set, since power and i2c interface are not implemented for it. Future patch will cover this to add PAD setting, power_init_board and etc. Peng Fan (3): pmic:pfuz100 add switch mode and more registers pmic:pfuze implement pmic_mode_init imx:mx6 set normal APS and standby PFM mode board/freescale/common/pfuze.c| 36 ++ board/freescale/common/pfuze.h| 1 + board/freescale/mx6qsabreauto/mx6qsabreauto.c | 5 +++ board/freescale/mx6sabresd/mx6sabresd.c | 6 ++- board/freescale/mx6sxsabresd/mx6sxsabresd.c | 6 ++- include/power/pfuze100_pmic.h | 53 +++ 6 files changed, 105 insertions(+), 2 deletions(-) -- 1.8.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] pmic:pfuz100 add switch mode and more registers
Add more pfuze register offset.
And switch mode definition.
Signed-off-by: Peng Fan
---
include/power/pfuze100_pmic.h | 53 +++
1 file changed, 53 insertions(+)
diff --git a/include/power/pfuze100_pmic.h b/include/power/pfuze100_pmic.h
index 1118489..7474afb 100644
--- a/include/power/pfuze100_pmic.h
+++ b/include/power/pfuze100_pmic.h
@@ -16,14 +16,34 @@ enum {
PFUZE100_SW1ABVOL = 0x20,
PFUZE100_SW1ABSTBY = 0x21,
+ PFUZE100_SW1ABOFF = 0x22,
+ PFUZE100_SW1ABMODE = 0x23,
PUZE_100_SW1ABCONF = 0x24,
PFUZE100_SW1CVOL= 0x2e,
PFUZE100_SW1CSTBY = 0x2f,
+ PFUZE100_SW1COFF= 0x30,
+ PFUZE100_SW1CMODE = 0x31,
PFUZE100_SW1CCONF = 0x32,
PFUZE100_SW2VOL = 0x35,
+ PFUZE100_SW2STBY= 0x36,
+ PFUZE100_SW2OFF = 0x37,
+ PFUZE100_SW2MODE= 0x38,
+ PFUZE100_SW2CONF= 0x39,
PFUZE100_SW3AVOL= 0x3c,
+ PFUZE100_SW3ASTBY = 0x3D,
+ PFUZE100_SW3AOFF= 0x3E,
+ PFUZE100_SW3AMODE = 0x3F,
+ PFUZE100_SW3ACONF = 0x40,
PFUZE100_SW3BVOL= 0x43,
+ PFUZE100_SW3BSTBY = 0x44,
+ PFUZE100_SW3BOFF= 0x45,
+ PFUZE100_SW3BMODE = 0x46,
+ PFUZE100_SW3BCONF = 0x47,
PFUZE100_SW4VOL = 0x4a,
+ PFUZE100_SW4STBY= 0x4b,
+ PFUZE100_SW4OFF = 0x4c,
+ PFUZE100_SW4MODE= 0x4d,
+ PFUZE100_SW4CONF= 0x4e,
PFUZE100_SWBSTCON1 = 0x66,
PFUZE100_VREFDDRCON = 0x6a,
PFUZE100_VSNVSVOL = 0x6b,
@@ -177,5 +197,38 @@ enum {
#define SWBST_MODE_AUTO(2 << 2)
#define SWBST_MODE_APS (2 << 3)
+/*
+ * Regulator Mode Control
+ *
+ * OFF: The regulator is switched off and the output voltage is discharged.
+ * PFM: In this mode, the regulator is always in PFM mode, which is useful
+ * at light loads for optimized efficiency.
+ * PWM: In this mode, the regulator is always in PWM mode operation
+ * regardless of load conditions.
+ * APS: In this mode, the regulator moves automatically between pulse
+ * skipping mode and PWM mode depending on load conditions.
+ *
+ * SWxMODE[3:0]
+ * Normal Mode | Standby Mode| value
+ * OFF OFF 0x0
+ * PWM OFF 0x1
+ * PFM OFF 0x3
+ * APS OFF 0x4
+ * PWM PWM 0x5
+ * PWM APS 0x6
+ * APS APS 0x8
+ * APS PFM 0xc
+ * PWM PFM 0xd
+ */
+#define OFF_OFF0x0
+#define PWM_OFF0x1
+#define PFM_OFF0x3
+#define APS_OFF0x4
+#define PWM_PWM0x5
+#define PWM_APS0x6
+#define APS_APS0x8
+#define APS_PFM0xc
+#define PWM_PFM0xd
+
int power_pfuze100_init(unsigned char bus);
#endif
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] imx:mx6 set normal APS and standby PFM mode
To normal mode, use APS switching mode.
To standy mode, use PFM switching mode.
Signed-off-by: Peng Fan
---
board/freescale/mx6qsabreauto/mx6qsabreauto.c | 5 +
board/freescale/mx6sabresd/mx6sabresd.c | 6 +-
board/freescale/mx6sxsabresd/mx6sxsabresd.c | 6 +-
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
index 59387ff..b29ff2b 100644
--- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
+++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
@@ -515,11 +515,16 @@ int board_spi_cs_gpio(unsigned bus, unsigned cs)
int power_init_board(void)
{
struct pmic *p;
+ unsigned int ret;
p = pfuze_common_init(I2C_PMIC);
if (!p)
return -ENODEV;
+ ret = pfuze_mode_init(p, APS_PFM);
+ if (ret < 0)
+ return -EIO;
+
return 0;
}
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 2f7198d..59544d9 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -631,12 +631,16 @@ int board_init(void)
int power_init_board(void)
{
struct pmic *p;
- unsigned int reg;
+ unsigned int reg, ret;
p = pfuze_common_init(I2C_PMIC);
if (!p)
return -ENODEV;
+ ret = pfuze_mode_init(p, APS_PFM);
+ if (ret < 0)
+ return -EIO;
+
/* Increase VGEN3 from 2.5 to 2.8V */
pmic_reg_read(p, PFUZE100_VGEN3VOL, ®);
reg &= ~LDO_VOL_MASK;
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index 5cc58ac..fbf3337 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -199,12 +199,16 @@ static struct i2c_pads_info i2c_pad_info1 = {
int power_init_board(void)
{
struct pmic *p;
- unsigned int reg;
+ unsigned int reg, ret;
p = pfuze_common_init(I2C_PMIC);
if (!p)
return -ENODEV;
+ ret = pfuze_mode_init(p, APS_PFM);
+ if (ret < 0)
+ return -EIO;
+
/* Enable power of VGEN5 3V3, needed for SD3 */
pmic_reg_read(p, PFUZE100_VGEN5VOL, ®);
reg &= ~LDO_VOL_MASK;
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: eth: asix88179: add ability to modify MAC address
Here is the promised patch, that enables U-Boot to modify the MAC
address of the AX88179.
Tested on RECS5250 (similar to Arndale5250)
Signed-off-by: Rene Griessl
---
drivers/usb/eth/asix88179.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/eth/asix88179.c b/drivers/usb/eth/asix88179.c
index b8ca720..b551540 100644
--- a/drivers/usb/eth/asix88179.c
+++ b/drivers/usb/eth/asix88179.c
@@ -271,6 +271,22 @@ static int asix_read_mac(struct eth_device *eth)
return 0;
}
+static int asix_write_mac(struct eth_device *eth)
+{
+ struct ueth_data *dev = (struct ueth_data *)eth->priv;
+ int ret;
+ u8 buf[ETH_ALEN];
+
+ memcpy(buf, eth->enetaddr, ETH_ALEN);
+
+ ret = asix_write_cmd(dev, AX_ACCESS_MAC, AX_NODE_ID, ETH_ALEN,
+ETH_ALEN, buf);
+ if (ret < 0)
+ debug("Failed to set MAC address: %02x\n", ret);
+
+ return ret;
+}
+
static int asix_basic_reset(struct ueth_data *dev)
{
struct asix_private *dev_priv = (struct asix_private *)dev->dev_priv;
@@ -686,6 +702,7 @@ int ax88179_eth_get_info(struct usb_device *dev, struct
ueth_data *ss,
eth->send = asix_send;
eth->recv = asix_recv;
eth->halt = asix_halt;
+ eth->write_hwaddr = asix_write_mac;
eth->priv = ss;
if (asix_basic_reset(ss))
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 00/12] cleanup and refactor lcd.c
Gentle ping.
On 12/08/2014 05:14 PM, Nikita Kiryanov wrote:
This series is a first step towards an end goal of merging all CONFIG_LCD
related functionality into CONFIG_VIDEO code. My plan is to start by refactoring
lcd.c into something cleaner (less ifdefs) and more modular (split code into
multiple files), then possibly refactor CONFIG_VIDEO code if needed, and then
finally: move CONFIG_LCD related functionality over to CONFIG_VIDEO code,
replacing as much CONFIG_LCD related code with CONFIG_VIDEO related code as
possible.
This specific step eliminates some unused code and refactors lcd console stuff
into its own file.
The patches ("lcd: rename console_(row|col)" to
"lcd: make lcd_drawchars() independant of lcd_base") are preparatory patches
meant to illustrate exactly what changed and where in the transition from lcd.c
to lcd_console.c, and are not necesserily code improvements when viewed out of
context.
Changes in V3:
- Function documentation
- Cache values of lcd_get(bg|fg)color() instead of calling the functions
multiple times.
The whole series was rebased over current mainline, and compile tested for arm
and powerpc.
Cc: Anatolij Gustschin
Cc: Wolfgang Denk
Cc: Simon Glass
Cc: Stephen Warren
Entire series:
Tested-by: Stephen Warren
Tested-by: Simon Glass
Nikita Kiryanov (12):
lcd: remove CONFIG_SYS_INVERT_COLORS
lcd: cleanup lcd_drawchars
mpc8xx_lcd: get rid of CONFIG_EDT32F10
lcd: remove LCD_MONOCHROME
lcd: rename console_(row|col)
lcd: replace CONSOLE_(ROWS|COLS) with variables
lcd: expand console api
lcd: get rid of COLOR_MASK
lcd: introduce getters for bg/fg color
lcd: make lcd_drawchars() independant of lcd_base
lcd: refactor lcd console stuff into its own file
lcd_console: remove unused defines
common/Makefile| 2 +-
common/lcd.c | 313 +
common/lcd_console.c | 211 ++
drivers/video/mpc8xx_lcd.c | 49 +--
drivers/video/pxa_lcd.c| 15 ---
include/configs/R360MPI.h | 1 -
include/lcd.h | 25 ++--
include/lcd_console.h | 86 +
8 files changed, 347 insertions(+), 355 deletions(-)
create mode 100644 common/lcd_console.c
create mode 100644 include/lcd_console.h
--
Regards,
Nikita Kiryanov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog: omap: Add handling for CONFIG_WATCHDOG_TIMEOUT_MSECS
On Thu, Jan 08, 2015 at 11:58:53AM +0100, Marek Belisko wrote: > This change add possibility to change watchdog timeout compile time. > Previous default value is kept when CONFIG_WATCHDOG_TIMEOUT_MSECS is > not defined in config file. Lets do this with a Kconfig option please, 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 00/18] Exynos: move i2c driver to dm api
Hello all, On 01/08/2015 12:28 PM, Przemyslaw Marczak wrote: This patchset adds support to driver model i2c api for Exynos i2c driver. Few boards are using this driver, but the board peripherals are not ported to the new api yet. So this can't be enabled with the full board functionality. In this case each Exynos5 based boards have fixed config dependencies Helloafor testing the dm i2c api with the new i2c driver. This will facilitate the peripheral porting. For test, just enable CONFIG_DM_I2C in exynos5-common.h. The i2c command should work with this as previous. This patchset also provides some changes related to Exynos4 boards. Most Exynos4 boards requires only pmic support, and this will be done with the new pmic framework soon. Przemyslaw Marczak (18): arndale: config: disable max77686 support exynos5250: config: disable max77686 driver smdk5250: config: enable max77686 driver support exynos4: dts: add missing i2c properties arndale: dts: add missing i2c aliases exynos5: pinmux: check flag for i2c config dm: i2c: s3c24x0: adjust to dm-i2c api exynos5: config: prepare for dm i2c support exynos5250: config: temporary disable sound for dm i2c arndale: config: temporary disable pmic for dm i2c exynos5-dt: config: temporary disable pmic for dm i2c snow: config: temporary disable cros ec i2c for dm i2c smdk5250: config: temporary disable pmic for dm i2c smdk5420: board: fix build warning for testing dm i2c peach-pi: config: temporary disable video parade for dm i2c peach-pit: config: temporary disable video parade for dm i2c trats2: board: cleanup power init code trats2: config: disable i2c peripherals if testing dm i2c arch/arm/cpu/armv7/exynos/pinmux.c | 27 ++-- arch/arm/dts/exynos4.dtsi | 24 ++-- arch/arm/dts/exynos5250-arndale.dts | 8 ++ board/samsung/smdk5420/smdk5420.c | 2 +- board/samsung/trats2/trats2.c | 144 +++- drivers/i2c/s3c24x0_i2c.c | 254 +++- include/configs/arndale.h | 5 +- include/configs/exynos5-common.h| 29 ++-- include/configs/exynos5-dt-common.h | 2 + include/configs/exynos5250-common.h | 5 +- include/configs/peach-pi.h | 2 + include/configs/peach-pit.h | 2 + include/configs/smdk5250.h | 4 + include/configs/snow.h | 4 +- include/configs/trats2.h| 17 ++- 15 files changed, 395 insertions(+), 134 deletions(-) The related patchset is also available here: https://github.com/bobenstein/u-boot/tree/dm-i2c-exynos Best regards, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] qspi:fsl implement AHB read
On 1/8/2015 7:21 PM, Jagan Teki wrote:
On 8 January 2015 at 15:48, Peng Fan wrote:
Hi, Jagan
On 1/8/2015 2:20 PM, Jagan Teki wrote:
On 8 January 2015 at 08:10, Peng Fan wrote:
The QSPI controller in i.MX 6SoloX and Vybrid supports reading data using
IP register and AHB bus.
The original driver only supports reading data from IP interface. The IC
team suggests to use AHB read which is faster then IP read. Using AHB
read,
we can directly memcpy, a "missed" access to the buffer will cause the
controller to clear the buffer and use the SEQID stored in bfgencr
register
to initiate a read from flash device.
So for the read connections - controller is connected through IP and
AHB interface
is it? and I'm thinking these two are bus protocols which can use any
peripheral unlike
qspi.
Yeah. fsl qspi controller is connected through IP and AHB interface.
register access through IP interface, Data access can use IP interface or
AHB interface. There is a memory mapped region for AHB data read. If want
to use AHB data read for QSPI, the controller should be configured by IP
interface, and then can use memcpy to read data. This patch adds the
configuration for using QSPI AHB read, this configuration is dedicated for
qspi.
Yes - I understand.
I'm thinking this ahb is a generic but not only specific to qspi the
read of this
interface should be generic somewhere in arch code so-that fsl_qspi will call
those routines on based on the need. - does it make sense?
The AHB read function is just memcpy. This original code use
"qspi_op_read" to read data from IP interface. In this patch, if
configured CONFIG_FSL_QSPI_AHB_READ, use qsp_ahb_read. This function is
very simple, as following:
+mcr_reg = qspi_read32(®s->mcr);
+
+qspi_write32(®s->mcr, QSPI_MCR_CLR_RXF_MASK | QSPI_MCR_CLR_TXF_MASK |
+QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE);
+
+/* Read out the data directly from the AHB buffer. */
+memcpy(rxbuf, (u8 *)(q->amba_base + q->sf_addr), len);
+
+qspi_write32(®s->mcr, mcr_reg);
It's just a wrapper function to call memcpy and save/restore qspi mcr
register, nothing else. I think it's not needed to wrap memcpy and move
it to arch code, since it is simple and contains qspi register save and
restore.
Since AHB bus is 64 bit width, we can not set MCR register using 32bit.
In
order to minimize code change, redefine QSPI_MCR_END_CFD_LE to 64bit
Little
endian but not 32bit Little endia.
Introduce a new configuration option CONFIG_SYS_FSL_QSPI_AHB. If want to
use AHB read, just define CONFIG_SYS_FSL_QSPI_AHB. If not, just ignore
it.
Actually if Vybrid is migrated to use AHB read, this option can be
removed and
IP read function can be discared. The reason to introduce this option
is that only i.MX SOC is tested in my side, no Vybrid platform for me.
So, where did you define?
The configuration is defined in board header file in mx6sxsabresd.h, using
#define CONFIG_SYS_FSL_QSPI_AHB.
Yes I saw in 2/2
In spi_setup_slave, the original piece code to set AHB is deleted, since
Vybrid platform does not use this to intiate AHB read. Instead, add
qspi_init_ahb_read function if defined CONFIG_SYS_FSL_QSPI_AHB.
Signed-off-by: Peng Fan
---
drivers/spi/fsl_qspi.c | 137
+
drivers/spi/fsl_qspi.h | 15 ++
2 files changed, 142 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index ad4f4ce..5e0b069 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -263,6 +263,110 @@ static void qspi_set_lut(struct fsl_qspi *qspi)
qspi_write32(®s->lckcr, QSPI_LCKCR_LOCK);
}
+#if defined(CONFIG_SYS_FSL_QSPI_AHB)
+/*
+ * If we have changed the content of the flash by writing or erasing,
+ * we need to invalidate the AHB buffer. If we do not do so, we may read
out
+ * the wrong data. The spec tells us reset the AHB domain and Serial
Flash
+ * domain at the same time.
+ */
+static inline void qspi_ahb_invalid(struct fsl_qspi *q)
+{
+ struct fsl_qspi_regs *regs = (struct fsl_qspi_regs *)q->reg_base;
+ u32 reg;
+
+ reg = qspi_read32(®s->mcr);
+ reg |= QSPI_MCR_SWRSTHD_MASK | QSPI_MCR_SWRSTSD_MASK;
+ qspi_write32(®s->mcr, reg);
+
+ /*
+* The minimum delay : 1 AHB + 2 SFCK clocks.
+* Delay 1 us is enough.
+*/
+ udelay(1);
+
+ reg &= ~(QSPI_MCR_SWRSTHD_MASK | QSPI_MCR_SWRSTSD_MASK);
+ qspi_write32(®s->mcr, reg);
+}
+
+/* Read out the data from the AHB buffer. */
+static inline void qspi_ahb_read(struct fsl_qspi *q, u8 *rxbuf, int len)
+{
+ struct fsl_qspi_regs *regs = (struct fsl_qspi_regs *)q->reg_base;
+ u32 mcr_reg;
+
+ mcr_reg = qspi_read32(®s->mcr);
+
+ qspi_write32(®s->mcr, QSPI_MCR_CLR_RXF_MASK |
QSPI_MCR_CLR_TXF_MASK |
+QSPI_MCR_RESERVED_MASK | QSPI_MCR_END_CFD_LE);
+
+ /* Read out the data directly from the AHB buffer. */
+ memcpy(rxbuf, (u8 *)(q->amba_bas
[U-Boot] [PATCH 18/18] trats2: config: disable i2c peripherals if testing dm i2c
Most i2c peripherals for this board doesn't support new i2c api. So CONFIG_DM_I2C on this board can be enabled for test only. The i2c command works fine with it. This is the first step before adding support to the new power framework soon. Signed-off-by: Przemyslaw Marczak Cc: Lukasz Majewski Cc: Jaehoon Chung Cc: Simon Glass Cc: Minkyu Kang --- include/configs/trats2.h | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/include/configs/trats2.h b/include/configs/trats2.h index 42481ab..8b099dd 100644 --- a/include/configs/trats2.h +++ b/include/configs/trats2.h @@ -159,15 +159,18 @@ #define CONFIG_RANDOM_UUID /* I2C */ -#include - +#if 0 /* For test */ +#define CONFIG_DM_I2C +#endif #define CONFIG_CMD_I2C - -#define CONFIG_SYS_I2C #define CONFIG_SYS_I2C_S3C24X0 #define CONFIG_SYS_I2C_S3C24X0_SPEED 10 #define CONFIG_SYS_I2C_S3C24X0_SLAVE 0 + +#ifndef CONFIG_DM_I2C +#define CONFIG_SYS_I2C #define CONFIG_MAX_I2C_NUM 8 + #define CONFIG_SYS_I2C_SOFT #define CONFIG_SYS_I2C_SOFT_SPEED 5 #define CONFIG_SYS_I2C_SOFT_SLAVE 0x00 @@ -177,6 +180,8 @@ #define CONFIG_SOFT_I2C_READ_REPEATED_START #define CONFIG_SYS_I2C_INIT_BOARD +#include + #ifndef __ASSEMBLY__ int get_soft_i2c_scl_pin(void); int get_soft_i2c_sda_pin(void); @@ -192,6 +197,7 @@ int get_soft_i2c_sda_pin(void); #define CONFIG_POWER_MUIC_MAX77693 #define CONFIG_POWER_FG_MAX77693 #define CONFIG_POWER_BATTERY_TRATS2 +#endif /* ifndef CONFIG_DM_I2C */ /* Security subsystem - enable hw_rand() */ #define CONFIG_EXYNOS_ACE_SHA @@ -203,11 +209,13 @@ int get_soft_i2c_sda_pin(void); #define CONFIG_MISC_INIT_R /* Download menu - Samsung common */ +#ifndef CONFIG_DM_I2C #define CONFIG_LCD_MENU #define CONFIG_LCD_MENU_BOARD /* Download menu - definitions for check keys */ #ifndef __ASSEMBLY__ +#include #include #define KEY_PWR_PMIC_NAME "MAX77686_PMIC" @@ -219,6 +227,7 @@ int get_soft_i2c_sda_pin(void); #define KEY_VOL_UP_GPIOEXYNOS4X12_GPIO_X22 #define KEY_VOL_DOWN_GPIO EXYNOS4X12_GPIO_X33 #endif /* __ASSEMBLY__ */ +#endif /* LCD console */ #define LCD_BPP LCD_COLOR16 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 17/18] trats2: board: cleanup power init code
This patch makes cleanup in:
- proper ifdefs to the power related functions
- check for pmic null pointers before use
And is a preparation for enabling dm i2c support.
Signed-off-by: Przemyslaw Marczak
Cc: Lukasz Majewski
Cc: Jaehoon Chung
Cc: Simon Glass
Cc: Minkyu Kang
---
board/samsung/trats2/trats2.c | 144 --
1 file changed, 82 insertions(+), 62 deletions(-)
diff --git a/board/samsung/trats2/trats2.c b/board/samsung/trats2/trats2.c
index a737749..caa885d 100644
--- a/board/samsung/trats2/trats2.c
+++ b/board/samsung/trats2/trats2.c
@@ -151,8 +151,6 @@ int exynos_early_init_f(void)
return 0;
}
-static int pmic_init_max77686(void);
-
int exynos_init(void)
{
struct exynos4_power *pwr =
@@ -174,6 +172,63 @@ int exynos_init(void)
return 0;
}
+#ifdef CONFIG_POWER
+static int pmic_init_max77686(void)
+{
+ struct pmic *p;
+
+ p = pmic_get("MAX77686_PMIC");
+ if (!p)
+ return -ENODEV;
+
+ if (pmic_probe(p))
+ return -1;
+
+ /* BUCK/LDO Output Voltage */
+ max77686_set_ldo_voltage(p, 21, 280); /* LDO21 VTF_2.8V */
+ max77686_set_ldo_voltage(p, 23, 330); /* LDO23 TSP_AVDD_3.3V*/
+ max77686_set_ldo_voltage(p, 24, 180); /* LDO24 TSP_VDD_1.8V */
+
+ /* BUCK/LDO Output Mode */
+ max77686_set_buck_mode(p, 1, OPMODE_STANDBY); /* BUCK1 VMIF_1.1V_AP */
+ max77686_set_buck_mode(p, 2, OPMODE_ON);/* BUCK2 VARM_1.0V_AP */
+ max77686_set_buck_mode(p, 3, OPMODE_ON);/* BUCK3 VINT_1.0V_AP */
+ max77686_set_buck_mode(p, 4, OPMODE_ON);/* BUCK4 VG3D_1.0V_AP */
+ max77686_set_buck_mode(p, 5, OPMODE_ON);/* BUCK5 VMEM_1.2V_AP */
+ max77686_set_buck_mode(p, 6, OPMODE_ON);/* BUCK6 VCC_SUB_1.35V*/
+ max77686_set_buck_mode(p, 7, OPMODE_ON);/* BUCK7 VCC_SUB_2.0V */
+ max77686_set_buck_mode(p, 8, OPMODE_OFF); /* VMEM_VDDF_2.85V */
+ max77686_set_buck_mode(p, 9, OPMODE_OFF); /* CAM_ISP_CORE_1.2V*/
+
+ max77686_set_ldo_mode(p, 1, OPMODE_LPM);/* LDO1 VALIVE_1.0V_AP*/
+ max77686_set_ldo_mode(p, 2, OPMODE_STANDBY);/* LDO2 VM1M2_1.2V_AP */
+ max77686_set_ldo_mode(p, 3, OPMODE_LPM);/* LDO3 VCC_1.8V_AP */
+ max77686_set_ldo_mode(p, 4, OPMODE_LPM);/* LDO4 VCC_2.8V_AP */
+ max77686_set_ldo_mode(p, 5, OPMODE_OFF);/* LDO5_VCC_1.8V_IO */
+ max77686_set_ldo_mode(p, 6, OPMODE_STANDBY);/* LDO6 VMPLL_1.0V_AP */
+ max77686_set_ldo_mode(p, 7, OPMODE_STANDBY);/* LDO7 VPLL_1.0V_AP */
+ max77686_set_ldo_mode(p, 8, OPMODE_LPM);/* LDO8 VMIPI_1.0V_AP */
+ max77686_set_ldo_mode(p, 9, OPMODE_OFF);/* CAM_ISP_MIPI_1.2*/
+ max77686_set_ldo_mode(p, 10, OPMODE_LPM); /* LDO10 VMIPI_1.8V_AP*/
+ max77686_set_ldo_mode(p, 11, OPMODE_STANDBY); /* LDO11 VABB1_1.8V_AP*/
+ max77686_set_ldo_mode(p, 12, OPMODE_LPM); /* LDO12 VUOTG_3.0V_AP*/
+ max77686_set_ldo_mode(p, 13, OPMODE_OFF); /* LDO13 VC2C_1.8V_AP */
+ max77686_set_ldo_mode(p, 14, OPMODE_STANDBY); /* VABB02_1.8V_AP */
+ max77686_set_ldo_mode(p, 15, OPMODE_STANDBY); /* LDO15 VHSIC_1.0V_AP*/
+ max77686_set_ldo_mode(p, 16, OPMODE_STANDBY); /* LDO16 VHSIC_1.8V_AP*/
+ max77686_set_ldo_mode(p, 17, OPMODE_OFF); /* CAM_SENSOR_CORE_1.2*/
+ max77686_set_ldo_mode(p, 18, OPMODE_OFF); /* CAM_ISP_SEN_IO_1.8V*/
+ max77686_set_ldo_mode(p, 19, OPMODE_OFF); /* LDO19 VT_CAM_1.8V */
+ max77686_set_ldo_mode(p, 20, OPMODE_ON);/* LDO20 VDDQ_PRE_1.8V*/
+ max77686_set_ldo_mode(p, 21, OPMODE_OFF); /* LDO21 VTF_2.8V */
+ max77686_set_ldo_mode(p, 22, OPMODE_OFF); /* LDO22 VMEM_VDD_2.8V*/
+ max77686_set_ldo_mode(p, 23, OPMODE_OFF); /* LDO23 TSP_AVDD_3.3V*/
+ max77686_set_ldo_mode(p, 24, OPMODE_OFF); /* LDO24 TSP_VDD_1.8V */
+ max77686_set_ldo_mode(p, 25, OPMODE_OFF); /* LDO25 VCC_3.3V_LCD */
+ max77686_set_ldo_mode(p, 26, OPMODE_OFF); /*LDO26 VCC_3.0V_MOTOR*/
+ return 0;
+}
+
int exynos_power_init(void)
{
int chrg;
@@ -239,10 +294,12 @@ int exynos_power_init(void)
return 0;
}
+#endif /* CONFIG_POWER */
#ifdef CONFIG_USB_GADGET
static int s5pc210_phy_control(int on)
{
+#ifdef CONFIG_POWER
int ret = 0;
unsigned int val;
struct pmic *p, *p_pmic, *p_muic;
@@ -299,7 +356,7 @@ static int s5pc210_phy_control(int on)
if (ret)
return -1;
-
+#endif
return 0;
}
@@ -319,97 +376,60 @@ int board_usb_init(int index, enum usb_init_type init)
int g_dnl_board_usb_cable_connected(void)
{
- struct pmic *muic = pmic_get("MAX77693_MUIC");
+#ifdef CONFIG_POWER
+ struct pmic *muic;
+
+ muic = pmic_get("MAX77693_MUIC");
if (!muic)
return 0
[U-Boot] [PATCH 09/18] exynos5250: config: temporary disable sound for dm i2c
This commit disables sound support for testing new i2c api for Exynos5250 boards. After move i2c part of sound drivers to the new i2c api, then this ifdef will be removed. Signed-off-by: Przemyslaw Marczak Cc: Akshay Saraswat Cc: Simon Glass Cc: Minkyu Kang --- include/configs/exynos5250-common.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/exynos5250-common.h b/include/configs/exynos5250-common.h index ae0e5ff..a6a766a 100644 --- a/include/configs/exynos5250-common.h +++ b/include/configs/exynos5250-common.h @@ -29,7 +29,9 @@ #define CONFIG_SYS_INIT_SP_ADDRCONFIG_IRAM_STACK /* Sound */ +#ifndef CONFIG_DM_I2C #define CONFIG_CMD_SOUND +#endif #ifdef CONFIG_CMD_SOUND #define CONFIG_SOUND #define CONFIG_I2S_SAMSUNG -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/18] arndale: config: temporary disable pmic for dm i2c
This commit disables pmic support for testing dm i2c api on arndale. There is no sense for move the current pmic framework to new i2c api, since the new power framework will be ready soon. Signed-off-by: Przemyslaw Marczak Cc: Akshay Saraswat Cc: Simon Glass Cc: Minkyu Kang --- include/configs/arndale.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/configs/arndale.h b/include/configs/arndale.h index 3ad4a9b..b3d3868 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -49,9 +49,10 @@ #define CONFIG_SYS_INIT_SP_ADDRCONFIG_IRAM_STACK /* PMIC */ +#ifndef CONFIG_DM_I2C #define CONFIG_PMIC #define CONFIG_POWER_I2C - +#endif #define CONFIG_PREBOOT #define CONFIG_S5P_PA_SYSRAM 0x0202 -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/18] arndale: dts: add missing i2c aliases
Without this alias setting, the seq numbers
of the i2c devices are wrong.
Signed-off-by: Przemyslaw Marczak
Cc: Simon Glass
Cc: Minkyu Kang
---
arch/arm/dts/exynos5250-arndale.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/exynos5250-arndale.dts
b/arch/arm/dts/exynos5250-arndale.dts
index 202f2ea..21c0a21 100644
--- a/arch/arm/dts/exynos5250-arndale.dts
+++ b/arch/arm/dts/exynos5250-arndale.dts
@@ -15,6 +15,14 @@
compatible = "samsung,arndale", "samsung,exynos5250";
aliases {
+ i2c0 = "/i2c@12c6";
+ i2c1 = "/i2c@12c7";
+ i2c2 = "/i2c@12c8";
+ i2c3 = "/i2c@12c9";
+ i2c4 = "/i2c@12ca";
+ i2c5 = "/i2c@12cb";
+ i2c6 = "/i2c@12cc";
+ i2c7 = "/i2c@12cd";
serial0 = "/serial@12C2";
console = "/serial@12C2";
};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 16/18] peach-pit: config: temporary disable video parade for dm i2c
Disable video parade driver if CONFIG_DM_I2C in exynos5-common.h is enabled. Signed-off-by: Przemyslaw Marczak Cc: Akshay Saraswat Cc: Simon Glass Cc: Minkyu Kang --- include/configs/peach-pit.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h index 6516a72..d0c40d3 100644 --- a/include/configs/peach-pit.h +++ b/include/configs/peach-pit.h @@ -32,7 +32,9 @@ #define CONFIG_SYS_PROMPT "Peach-Pit # " #define CONFIG_IDENT_STRING" for Peach-Pit" +#ifndef CONFIG_DM_I2C #define CONFIG_VIDEO_PARADE +#endif /* Display */ #define CONFIG_LCD -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/18] snow: config: temporary disable cros ec i2c for dm i2c
Disable cros ec i2c driver if CONFIG_DM_I2C in exynos5-common.h is enabled. Signed-off-by: Przemyslaw Marczak Cc: Akshay Saraswat Cc: Simon Glass Cc: Minkyu Kang --- include/configs/snow.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/snow.h b/include/configs/snow.h index 7eaa586..b42766d 100644 --- a/include/configs/snow.h +++ b/include/configs/snow.h @@ -19,10 +19,10 @@ #include #include - +#ifndef CONFIG_DM_I2C #define CONFIG_CROS_EC_I2C /* Support CROS_EC over I2C */ #define CONFIG_POWER_TPS65090_I2C - +#endif #define CONFIG_BOARD_COMMON #define CONFIG_ARCH_EARLY_INIT_R -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/18] exynos5: pinmux: check flag for i2c config
Some versions of Exynos5 supports High-Speed I2C,
on few interfaces, this change allows support this.
Signed-off-by: Przemyslaw Marczak
Cc: Simon Glass
Cc: Akshay Saraswat
Cc: Minkyu Kang
---
arch/arm/cpu/armv7/exynos/pinmux.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 94d0297..b2c5494 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -266,22 +266,33 @@ static void exynos5_sromc_config(int flags)
static void exynos5_i2c_config(int peripheral, int flags)
{
+ int func01, func23;
+
+/* flags only for High-Speed I2C */
+ if (flags) {
+ func01 = 4;
+ func23 = 4;
+ } else {
+ func01 = 2;
+ func23 = 3;
+ }
+
switch (peripheral) {
case PERIPH_ID_I2C0:
- gpio_cfg_pin(EXYNOS5_GPIO_B30, S5P_GPIO_FUNC(0x2));
- gpio_cfg_pin(EXYNOS5_GPIO_B31, S5P_GPIO_FUNC(0x2));
+ gpio_cfg_pin(EXYNOS5_GPIO_B30, S5P_GPIO_FUNC(func01));
+ gpio_cfg_pin(EXYNOS5_GPIO_B31, S5P_GPIO_FUNC(func01));
break;
case PERIPH_ID_I2C1:
- gpio_cfg_pin(EXYNOS5_GPIO_B32, S5P_GPIO_FUNC(0x2));
- gpio_cfg_pin(EXYNOS5_GPIO_B33, S5P_GPIO_FUNC(0x2));
+ gpio_cfg_pin(EXYNOS5_GPIO_B32, S5P_GPIO_FUNC(func01));
+ gpio_cfg_pin(EXYNOS5_GPIO_B33, S5P_GPIO_FUNC(func01));
break;
case PERIPH_ID_I2C2:
- gpio_cfg_pin(EXYNOS5_GPIO_A06, S5P_GPIO_FUNC(0x3));
- gpio_cfg_pin(EXYNOS5_GPIO_A07, S5P_GPIO_FUNC(0x3));
+ gpio_cfg_pin(EXYNOS5_GPIO_A06, S5P_GPIO_FUNC(func23));
+ gpio_cfg_pin(EXYNOS5_GPIO_A07, S5P_GPIO_FUNC(func23));
break;
case PERIPH_ID_I2C3:
- gpio_cfg_pin(EXYNOS5_GPIO_A12, S5P_GPIO_FUNC(0x3));
- gpio_cfg_pin(EXYNOS5_GPIO_A13, S5P_GPIO_FUNC(0x3));
+ gpio_cfg_pin(EXYNOS5_GPIO_A12, S5P_GPIO_FUNC(func23));
+ gpio_cfg_pin(EXYNOS5_GPIO_A13, S5P_GPIO_FUNC(func23));
break;
case PERIPH_ID_I2C4:
gpio_cfg_pin(EXYNOS5_GPIO_A20, S5P_GPIO_FUNC(0x3));
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
