[U-Boot] [PATCH 2/2] ti_armv7_keystone2: Update addr_mon variable
As boot monitor contains a mkimage header, it can be loaded at any location.
So, have a common addr_mon address across all keystone2 SoCs. And also
making sure that boot monitor is installed early during default boot to
avoid any overlapping with other images.
Signed-off-by: Lokesh Vutla
---
- This is based on top of https://patchwork.ozlabs.org/patch/670426/
include/configs/k2e_evm.h| 1 -
include/configs/k2g_evm.h| 6 ++
include/configs/k2hk_evm.h | 1 -
include/configs/k2l_evm.h| 1 -
include/configs/ti_armv7_keystone2.h | 5 +++--
5 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h
index 7eaab87..8d6471a 100644
--- a/include/configs/k2e_evm.h
+++ b/include/configs/k2e_evm.h
@@ -18,7 +18,6 @@
#define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\
DEFAULT_FW_INITRAMFS_BOOT_ENV \
"boot=ubi\0"\
- "addr_mon=0x0c14\0" \
"args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\
"root=ubi0:rootfs rootflags=sync rw ubi.mtd=ubifs,2048\0" \
"name_fdt=keystone-k2e-evm.dtb\0" \
diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
index d73543f..a145445 100644
--- a/include/configs/k2g_evm.h
+++ b/include/configs/k2g_evm.h
@@ -24,7 +24,6 @@
"bootpart=0:2\0"\
"bootdir=/boot\0" \
"rd_spec=-\0" \
- "addr_mon=0x0c04\0" \
"args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\
"root=ubi0:rootfs rootflags=sync rw ubi.mtd=ubifs,2048\0" \
"name_fdt=keystone-k2g-evm.dtb\0" \
@@ -44,9 +43,8 @@
#define CONFIG_BOOTCOMMAND \
"run envboot; " \
"run set_name_pmmc init_${boot} init_fw_rd_${boot} "\
- "get_pmmc_${boot} run_pmmc "\
- "get_fdt_${boot} get_mon_${boot} get_kern_${boot} " \
- "run_mon run_kern"
+ "get_pmmc_${boot} run_pmmc get_mon_${boot} run_mon "\
+ "get_fdt_${boot} get_kern_${boot} run_kern"
#include
diff --git a/include/configs/k2hk_evm.h b/include/configs/k2hk_evm.h
index 0256f0e..913d454 100644
--- a/include/configs/k2hk_evm.h
+++ b/include/configs/k2hk_evm.h
@@ -18,7 +18,6 @@
#define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\
DEFAULT_FW_INITRAMFS_BOOT_ENV \
"boot=ubi\0"\
- "addr_mon=0x0c5f\0" \
"args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\
"root=ubi0:rootfs rootflags=sync rw ubi.mtd=ubifs,2048\0" \
"name_fdt=keystone-k2hk-evm.dtb\0" \
diff --git a/include/configs/k2l_evm.h b/include/configs/k2l_evm.h
index 2322ab2..395e61c 100644
--- a/include/configs/k2l_evm.h
+++ b/include/configs/k2l_evm.h
@@ -18,7 +18,6 @@
#define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\
DEFAULT_FW_INITRAMFS_BOOT_ENV \
"boot=ubi\0"\
- "addr_mon=0x0c14\0" \
"args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\
"root=ubi0:rootfs rootflags=sync rw ubi.mtd=ubifs,4096\0" \
"name_fdt=keystone-k2l-evm.dtb\0" \
diff --git a/include/configs/ti_armv7_keystone2.h
b/include/configs/ti_armv7_keystone2.h
index c8df48a..c0c5d87 100644
--- a/include/configs/ti_armv7_keystone2.h
+++ b/include/configs/ti_armv7_keystone2.h
@@ -250,6 +250,7 @@
"addr_ubi=0x8200\0" \
"addr_secdb_key=0xc00\0"\
"name_kern=zImage\0"\
+ "addr_mon=0x8700\0" \
"run_mon=mon_install ${addr_mon}\0" \
"run_kern=bootz ${loadaddr} ${rd_spec} ${fdtaddr}\0"\
"init_net=run args_all args_net\0" \
@@ -294,8 +295,8 @@
#ifndef CONFIG_BOOTCOMMAND
#define CONFIG_BOOTCOMMAND \
- "run init_${boot} init_fw_rd_${boot} get_fdt_${boot} " \
- "get_mon_${boot} get_kern_${boot} run_mon run_ker
[U-Boot] [PATCH 1/2] ARM: keystone2: Add support for parsing monitor header
Given that boot monitor image is being generated to a specific target location
depending on the SoC and U-boot relies on addr_mon env variable to be aligned
with boot monitor target location. When ever the target address gets updated in
boot monitor, it is difficult to sync between u-boot and boot monitor and also
there is no way to update user that boot monitor image is updated.
To avoid this problem, boot monitor image is being generated with mkimage
header. Adding support in mon_install command for parsing this header.
Signed-off-by: Suman Anna
Signed-off-by: Lokesh Vutla
---
arch/arm/mach-keystone/cmd_mon.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-keystone/cmd_mon.c b/arch/arm/mach-keystone/cmd_mon.c
index 6a9bdc9..591e758 100644
--- a/arch/arm/mach-keystone/cmd_mon.c
+++ b/arch/arm/mach-keystone/cmd_mon.c
@@ -9,14 +9,16 @@
#include
#include
+#include
#include
asm(".arch_extension sec\n\t");
static int do_mon_install(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
{
- u32 addr, dpsc_base = 0x1E8, freq;
+ u32 addr, dpsc_base = 0x1E8, freq, load_addr, size;
int rcode = 0;
+ struct image_header *header;
if (argc < 2)
return CMD_RET_USAGE;
@@ -25,9 +27,21 @@ static int do_mon_install(cmd_tbl_t *cmdtp, int flag, int
argc,
addr = simple_strtoul(argv[1], NULL, 16);
- rcode = mon_install(addr, dpsc_base, freq);
- printf("## installed monitor, freq [%d], status %d\n",
- freq, rcode);
+ header = (struct image_header *)addr;
+
+ if (image_get_magic(header) != IH_MAGIC) {
+ printf("## Please update monitor image\n");
+ return -EFAULT;
+ }
+
+ load_addr = image_get_load(header);
+ size = image_get_data_size(header);
+ memcpy((void *)load_addr, (void *)(addr + sizeof(struct image_header)),
+ size);
+
+ rcode = mon_install(load_addr, dpsc_base, freq);
+ printf("## installed monitor @ 0x%x, freq [%d], status %d\n",
+ load_addr, freq, rcode);
return 0;
}
--
2.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] ARM: keystone2: Add support for parsing monitor header
This series adds support for parsing mkimage header on boot monitor image. Update boot-monitor code is available here[1] [1] git://git.ti.com/processor-firmware/ks2-boot-monitor.git Lokesh Vutla (2): ARM: keystone2: Add support for parsing monitor header ti_armv7_keystone2: Update addr_mon variable arch/arm/mach-keystone/cmd_mon.c | 22 ++ include/configs/k2e_evm.h| 1 - include/configs/k2g_evm.h| 6 ++ include/configs/k2hk_evm.h | 1 - include/configs/k2l_evm.h| 1 - include/configs/ti_armv7_keystone2.h | 5 +++-- 6 files changed, 23 insertions(+), 13 deletions(-) -- 2.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/12] sh: change arch and boards code to generic board
Hi,
Sorry, reply is late..
I will check your patches this weekend.
Best regards,
Nobuhiro
2016-08-31 18:44 GMT+09:00 Vladimir Zapolskiy :
> On 06.08.2016 21:21, Vladimir Zapolskiy wrote:
>> The changeset implements initial support of relocatable U-Boot code
>> for SH2/SH3/SH4 architectures and boards, as weel as it restores
>> a possibility to boot U-Boot on SH boards, which has not been converted
>> to generic board in time (for more details see commit f41e6088eb1
>> ("sh: Fix build errors for generic board")). Special attention from
>> maintainers of all touched boards is required, due to inaccessibility
>> of hardware for me it would be a troublesome task.
>>
>> Now code/data initialization and relocation in general resemble the
>> procedure on ARM with minor peculiarities (same one relocation from a
>> storage device if calculated reloc_off == 0, otherwise two relocations),
>> however please note that the change does *not* add PIE support (only PIC),
>> so it may end up that there are persistent pointers to some non-relocated
>> data, this point requires better investion.
>>
>> There is a runtime dependency on one generic change in common/board_f.c,
>> see patch https://patchwork.ozlabs.org/patch/656371/ , also only r2dplus
>> board is actually converted to support new arcitectural changes,
>> application of patch 12/12 depends on SH7751 PCI fixes found at
>> https://patchwork.ozlabs.org/patch/656373/ :
>>
>> -#define CONFIG_SYS_TEXT_BASE 0x8FFC
>> +#define CONFIG_SYS_TEXT_BASE 0x8FE0
>>
>> This r2dplus board change allows immediately check the correctness of
>> the series on a r2dplus qemu target, note that the second copy is
>> not avoided in this case, also for simplicity SDRAM area up to text base
>> is large enough to store malloc pool and two copies of loaded code/data.
>>
>> Board maintainers may pay attention to CONFIG_SYS_MALLOC_CLEAR_ON_INIT,
>> CONFIG_NEEDS_MANUAL_RELOC, CONFIG_SYS_GENERIC_GLOBAL_DATA etc. options.
>> To let know about the change and to continue with the completion of
>> the final step of board conversions to generic board I include all
>> SH2/SH3/SH4 board maintainers into Cc list, please update your board
>> configs appropriately.
>>
>> The change was tested on one custom SH4 (SH7551R) board, r2dplus qemu
>> target (see also SH7751 PCI change under review), the rest of the boards
>> are compile tested only.
>>
>> Multiple kudos to Simon for great patience and a decision to not remove
>> the code.
>>
>> Any further improvements are welcome, especially it's worth to mention
>> the anticipated convertion to PIE.
>>
>> Vladimir Zapolskiy (12):
>> sh4: use single u-boot linker script for all boards
>> sh: place board lowlevel_init code in the beginning of .text
>> sh: define entry point and reloc_dst inside a linker script
>> sh: add MEMORY command to a shared linker script
>> sh: remove undefined DEBUG preprocessor token from board config files
>> sh: define CONFIG_DISPLAY_BOARDINFO to print board information
>> sh: add common dram_init() function for all boards
>> sh: add shared relocate_code() function and call board_init_r()
>> sh4: fix start.S by calling board_init_f() after first code relocation
>> sh: share the correct version of start.S among all cpus
>> sh: generate position independent code for all platforms
>> r2dplus: fixup CONFIG_SYS_TEXT_BASE to account arch/sh changes
>>
>
> Ping.
>
> --
> Best wishes,
> Vladimir
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mx6: fix USB bmode to use reserved value
On 9/15/2016 3:04 PM, Stefan Agner wrote:
> From: Stefan Agner
>
> Currently the bmode "usb" uses BOOT_CFG1 to 0x01, -which means
> BOOT_CFG1[7:4] is set to b. According to Table 8-7 Boot
> Device Selection this is NOR/OneNAND and not Reserved.
>
> Use 0x10 which leads to b0001, which is a Reserved boot device.
> With that the SoC reliably falls back to the serial loader.
>
> Cc: Troy Kisky
> Signed-off-by: Stefan Agner
> ---
>
> arch/arm/cpu/armv7/mx6/soc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index 88fcfdc..c343c57 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -494,7 +494,7 @@ void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
> const struct boot_mode soc_boot_modes[] = {
> {"normal", MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
> /* reserved value should start rom usb */
> - {"usb", MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
> + {"usb", MAKE_CFGVAL(0x10, 0x00, 0x00, 0x00)},
> {"sata",MAKE_CFGVAL(0x20, 0x00, 0x00, 0x00)},
> {"ecspi1:0",MAKE_CFGVAL(0x30, 0x00, 0x00, 0x08)},
> {"ecspi1:1",MAKE_CFGVAL(0x30, 0x00, 0x00, 0x18)},
>
Tested-by: Troy Kisky
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] drivers: usb: fsl-dt-fixup: Fix the dt for multiple USB nodes in single traversal of device tree
On 09/15/2016 12:29 AM, york sun wrote:
> On 09/14/2016 02:35 PM, Marek Vasut wrote:
>> On 09/14/2016 07:22 AM, Sriram Dash wrote:
From: Sriram Dash [mailto:sriram.d...@nxp.com]
>>>
>>> Hello Marek,
>>>
>>> Any comments?
>>
>> Waiting for York to review this.
>>
>> It's a bulky patch V2 without changelog, shall I review the whole thing
>> again ?
>>
For FSL USB node fixup, the dt is walked multiple times for fixing erratum
and phy
type. This patch walks the tree and fixes the node till no more USB nodes
are left.
Signed-off-by: Sriram Dash
Signed-off-by: Rajesh Bhagat
---
drivers/usb/common/fsl-dt-fixup.c | 108
+-
1 file changed, 47 insertions(+), 61 deletions(-)
diff --git a/drivers/usb/common/fsl-dt-fixup.c
b/drivers/usb/common/fsl-dt-fixup.c
index 9c48852..df785a6 100644
--- a/drivers/usb/common/fsl-dt-fixup.c
+++ b/drivers/usb/common/fsl-dt-fixup.c
@@ -54,25 +54,19 @@ static int fdt_usb_get_node_type(void *blob, int
start_offset, }
static int fdt_fixup_usb_mode_phy_type(void *blob, const char *mode,
- const char *phy_type, int start_offset)
+ const char *phy_type, int node_offset,
+ const char **node_type)
{
const char *prop_mode = "dr_mode";
const char *prop_type = "phy_type";
- const char *node_type = NULL;
- int node_offset;
- int err;
-
- err = fdt_usb_get_node_type(blob, start_offset,
- &node_offset, &node_type);
- if (err < 0)
- return err;
+ int err = 0;
if (mode) {
err = fdt_setprop(blob, node_offset, prop_mode, mode,
strlen(mode) + 1);
if (err < 0)
printf("WARNING: could not set %s for %s: %s.\n",
- prop_mode, node_type, fdt_strerror(err));
+ prop_mode, *node_type, fdt_strerror(err));
}
if (phy_type) {
@@ -80,52 +74,48 @@ static int fdt_fixup_usb_mode_phy_type(void *blob,
const
char *mode,
strlen(phy_type) + 1);
if (err < 0)
printf("WARNING: could not set %s for %s: %s.\n",
- prop_type, node_type, fdt_strerror(err));
+ prop_type, *node_type, fdt_strerror(err));
}
- return node_offset;
+ return err;
}
static int fdt_fixup_usb_erratum(void *blob, const char *prop_erratum,
- const char *controller_type, int start_offset)
+ const char *controller_type, int node_offset,
+ const char **node_type)
{
- int node_offset, err;
- const char *node_type = NULL;
+ int err = -1;
const char *node_name = NULL;
- err = fdt_usb_get_node_type(blob, start_offset,
- &node_offset, &node_type);
- if (err < 0)
- return err;
-
- if (!strcmp(node_type, FSL_USB2_MPH) || !strcmp(node_type,
FSL_USB2_DR))
+ if (!strcmp(*node_type, FSL_USB2_MPH) ||
+ !strcmp(*node_type, FSL_USB2_DR))
node_name = CHIPIDEA_USB2;
else
- node_name = node_type;
+ node_name = *node_type;
if (strcmp(node_name, controller_type))
return err;
err = fdt_setprop(blob, node_offset, prop_erratum, NULL, 0);
if (err < 0) {
printf("ERROR: could not set %s for %s: %s.\n",
- prop_erratum, node_type, fdt_strerror(err));
+ prop_erratum, *node_type, fdt_strerror(err));
}
- return node_offset;
+ return err;
}
-static int fdt_fixup_erratum(int *usb_erratum_off, void *blob,
+static int fdt_fixup_erratum(int node_offset, void *blob,
const char *controller_type, char *str,
- bool (*has_erratum)(void))
+ bool (*has_erratum)(void), const char **node_type)
{
char buf[32] = {0};
snprintf(buf, sizeof(buf), "fsl,usb-erratum-%s", str);
if (!has_erratum())
return -EINVAL;
- *usb_erratum_off = fdt_fixup_usb_erratum(blob, buf, controller_type,
- *usb_erratum_off);
- if (*usb_erratum_off < 0)
+ node_offset = fdt_fixup_usb_erratum(blob, buf, controller_type,
+ node_offset, node_type);
+ if (node_offset < 0)
return -ENOSPC;
debug("Adding USB erratum %s\n", str);
Re: [U-Boot] [PATCH v3] drivers: usb: xhci-fsl: Implement Erratum A-010151 for FSL USB3 controller
On 09/15/2016 08:31 AM, Sriram Dash wrote:
>> From: Marek Vasut [mailto:ma...@denx.de]
>> On 09/14/2016 07:15 AM, Sriram Dash wrote:
>>> Currently the controller by default enables the Receive Detect feature
>>> in P3 mode in USB 3.0 PHY. However, USB 3.0 PHY does not reliably
>>> support receive detection in P3 mode.
>>> Enabling the USB3 controller to configure USB in P2 mode whenever the
>>> Receive Detect feature is required.
>>>
>>> Signed-off-by: Sriram Dash
>>> Signed-off-by: Rajesh Bhagat
>>> ---
>>> Changes in v3:
>>> - Fixing conflicts and repost
>>
>> Changelog of this verbosity is completely useless.
>>
>
> I will take care the next time.
>
>>> Changes in v2:
>>> - Do Soc ver checking for applying erratum
>>>
>>> drivers/usb/common/fsl-errata.c | 26 ++
>>> drivers/usb/host/xhci-dwc3.c| 5 +
>>> drivers/usb/host/xhci-fsl.c | 8
>>> include/fsl_usb.h | 1 +
>>> include/linux/usb/dwc3.h| 2 ++
>>> 5 files changed, 42 insertions(+)
>>>
>>> diff --git a/drivers/usb/common/fsl-errata.c
>>> b/drivers/usb/common/fsl-errata.c index 183bf2b..f2bffba 100644
>>> --- a/drivers/usb/common/fsl-errata.c
>>> +++ b/drivers/usb/common/fsl-errata.c
>>> @@ -190,4 +190,30 @@ bool has_erratum_a008751(void)
>>> return false;
>>> }
>>>
>>> +bool has_erratum_a010151(void)
>>> +{
>>> + u32 svr = get_svr();
>>> + u32 soc = SVR_SOC_VER(svr);
>>> +
>>> + switch (soc) {
>>> +#ifdef CONFIG_ARM64
>>> + case SVR_LS2080A:
>>> + case SVR_LS2085A:
>>> + case SVR_LS1046A:
>>> + case SVR_LS1012A:
>>> + return IS_SVR_REV(svr, 1, 0);
>>> + case SVR_LS1043A:
>>> + return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 1, 1); #endif
>>> +#ifdef CONFIG_LS102XA
>>> + case SOC_VER_LS1020:
>>> + case SOC_VER_LS1021:
>>> + case SOC_VER_LS1022:
>>> + case SOC_VER_SLS1020:
>>> + return IS_SVR_REV(svr, 2, 0);
>>> +#endif
>>> + }
>>> + return false;
>>> +}
>>> +
>>> #endif
>>> diff --git a/drivers/usb/host/xhci-dwc3.c
>>> b/drivers/usb/host/xhci-dwc3.c index 33961cd..adbd9b5 100644
>>> --- a/drivers/usb/host/xhci-dwc3.c
>>> +++ b/drivers/usb/host/xhci-dwc3.c
>>> @@ -97,3 +97,8 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val)
>>> setbits_le32(&dwc3_reg->g_fladj, GFLADJ_30MHZ_REG_SEL |
>>> GFLADJ_30MHZ(val));
>>> }
>>> +
>>> +void dwc3_set_rxdetect_power_mode(struct dwc3 *dwc3_reg, u32 val) {
>>> + setbits_le32(&dwc3_reg->g_usb3pipectl[0], val);
>>
>> So what would happen if I wanted to clean some bits instead ?
>
> Setting the Rx detect in P2 mode is a one time job,
> and it does not change. Hence, IMO, the clear bit
> functionality is not required.
Until an SoC comes which has some bits set there and someone wants to
clear them . At which point, this code will serve as a trap .
>> Why do you even need a dedicated function to write a single register?
>>
>
> The dwc3 phy for the specific controller version
This should be explicitly documented with a comment here.
> does not reliably
> support Rx Detect in P3 mode(P3 is the default setting). So, this
> setting can be used by any other Soc, apart from freescale. IMO, this
> function is required.
So why won't such a system call single register write directly ?
>>> +}
>>> diff --git a/drivers/usb/host/xhci-fsl.c b/drivers/usb/host/xhci-fsl.c
>>> index 0e3e056..9297ced 100644
>>> --- a/drivers/usb/host/xhci-fsl.c
>>> +++ b/drivers/usb/host/xhci-fsl.c
>>> @@ -84,6 +84,14 @@ static int fsl_xhci_core_init(struct fsl_xhci *fsl_xhci)
>>> /* Change beat burst and outstanding pipelined transfers requests */
>>> fsl_xhci_set_beat_burst_length(fsl_xhci->dwc3_reg);
>>>
>>> + /*
>>> +* A-010151: USB controller to configure USB in P2 mode
>>> +* whenever the Receive Detect feature is required
>>> +*/
>>> + if (has_erratum_a010151())
>>> + dwc3_set_rxdetect_power_mode(fsl_xhci->dwc3_reg,
>>> +DWC3_GUSB3PIPECTL_DISRXDETP3);
>>
>> Can't you parse these errata infos from device tree ?
>>
>
> Currently, all the freescale Socs using this controller are not using DM.
I am asking about device tree, not driver model. These two are orthogonal.
> Shall we proceed with this solution currently, and then when the DM is
> supported by all Socs, modify the implementation according to device tree?
> What do you suggest?
>
[...]
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] apalis_t30: colibri_imx7: colibri_t30: fix ethernet functionality
On 09/15/2016 12:54 AM, Marcel Ziswiler wrote:
> Since commit aa7a648747d8c704a9a81c9e493d386930724e9d
> ("net: Stop including NFS overhead in defragment max") the following
> has been reproducibly observed while trying to transfer data over TFTP:
>
> Load address: 0x80408000
> Loading: EHCI timed out on TD - token=0x8008d80
> T EHCI timed out on TD - token=0x88008d80
> Rx: failed to receive: -5
>
> This patch fixes this by lowering our TFTP block size to be within the
> standard maximal de-fragmentation aka IP packet size again.
>
> Signed-off-by: Marcel Ziswiler
Applied to u-boot-usb/master, although this probably should've gone via
u-boot-imx or so.
Thanks!
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] imx: mx6: fix USB bmode to use reserved value
From: Stefan Agner
Currently the bmode "usb" uses BOOT_CFG1 to 0x01, -which means
BOOT_CFG1[7:4] is set to b. According to Table 8-7 Boot
Device Selection this is NOR/OneNAND and not Reserved.
Use 0x10 which leads to b0001, which is a Reserved boot device.
With that the SoC reliably falls back to the serial loader.
Cc: Troy Kisky
Signed-off-by: Stefan Agner
---
arch/arm/cpu/armv7/mx6/soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
index 88fcfdc..c343c57 100644
--- a/arch/arm/cpu/armv7/mx6/soc.c
+++ b/arch/arm/cpu/armv7/mx6/soc.c
@@ -494,7 +494,7 @@ void imx_get_mac_from_fuse(int dev_id, unsigned char *mac)
const struct boot_mode soc_boot_modes[] = {
{"normal", MAKE_CFGVAL(0x00, 0x00, 0x00, 0x00)},
/* reserved value should start rom usb */
- {"usb", MAKE_CFGVAL(0x01, 0x00, 0x00, 0x00)},
+ {"usb", MAKE_CFGVAL(0x10, 0x00, 0x00, 0x00)},
{"sata",MAKE_CFGVAL(0x20, 0x00, 0x00, 0x00)},
{"ecspi1:0",MAKE_CFGVAL(0x30, 0x00, 0x00, 0x08)},
{"ecspi1:1",MAKE_CFGVAL(0x30, 0x00, 0x00, 0x18)},
--
2.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] image-fit: switch ENOLINK to ENOENT
On Thu, Sep 15, 2016 at 04:08:33PM +0200, Mario Six wrote:
> Hi Stefan,
>
> I also see the same error on our Armada board. It stems from the fact that
> boot_get_ramdisk in common/image.c treats a ENOLINK different from all other
> errors (which the patch changed into a ENOENT). The following patch fixes the
> problem on our board:
>
> diff --git a/common/image.c b/common/image.c
> index 7ad04ca..c8d9bc8 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -1078,7 +1078,7 @@ int boot_get_ramdisk(int argc, char * const
> argv[], bootm_headers_t *images,
> rd_addr = map_to_sysmem(images->fit_hdr_os);
> rd_noffset = fit_get_node_from_config(images,
> FIT_RAMDISK_PROP, rd_addr);
> -if (rd_noffset == -ENOLINK)
> +if (rd_noffset == -ENOENT)
> return 0;
> else if (rd_noffset < 0)
> return 1;
>
> So, yes, 2016.09 breaks Armada, apparently.
The callers of the proposed/rejected kwboot.c errno diff were all
checked but the test of the result in the caller of this one
seems to have been missed indeed.
Sorry for missing this and
Reviewed-by: Jonathan Gray
>
> Best regards,
>
> Mario
>
> On Thu, Sep 15, 2016 at 2:49 PM, Stefan Roese wrote:
> > Hi Tom,
> > Hi Jonathan,
> >
> > On 03.09.2016 00:30, Jonathan Gray wrote:
> >> ENOLINK is not required by POSIX and does not exist on OpenBSD
> >> and likely other systems.
> >>
> >> Signed-off-by: Jonathan Gray
> >> ---
> >> common/image-fit.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/common/image-fit.c b/common/image-fit.c
> >> index d8d4e95..79c0375 100644
> >> --- a/common/image-fit.c
> >> +++ b/common/image-fit.c
> >> @@ -1566,7 +1566,7 @@ int fit_get_node_from_config(bootm_headers_t
> >> *images, const char *prop_name,
> >> noffset = fit_conf_get_prop_node(fit_hdr, cfg_noffset, prop_name);
> >> if (noffset < 0) {
> >> debug("* %s: no '%s' in config\n", prop_name, prop_name);
> >> - return -ENOLINK;
> >> + return -ENOENT;
> >> }
> >>
> >> return noffset;
> >>
> >
> > This patch breaks Linux booting via FIT-image on Marvell Armada
> > XP for me. Here a short log with this patch applied:
> >
> > ## Loading kernel from FIT Image at 0200 ...
> >Using 'conf@1' configuration
> >Trying 'kernel@1' kernel subimage
> > Description: Linux kernel
> > Type: Kernel Image
> > Compression: uncompressed
> > Data Start: 0x02f4
> > Data Size:5065728 Bytes = 4.8 MiB
> > Architecture: ARM
> > OS: Linux
> > Load Address: 0x8000
> > Entry Point: 0x8000
> > Hash algo:sha1
> > Hash value: 11ddefa0b68cbc5db9d84b0fd74ec67da155fada
> >Verifying Hash Integrity ... sha1+ OK
> > Ramdisk image is corrupt or invalid
> >
> >
> > And this is how is should look like:
> >
> > ## Loading kernel from FIT Image at 0200 ...
> >Using 'conf@1' configuration
> >Trying 'kernel@1' kernel subimage
> > Description: Linux kernel
> > Type: Kernel Image
> > Compression: uncompressed
> > Data Start: 0x02f4
> > Data Size:5065728 Bytes = 4.8 MiB
> > Architecture: ARM
> > OS: Linux
> > Load Address: 0x8000
> > Entry Point: 0x8000
> > Hash algo:sha1
> > Hash value: 11ddefa0b68cbc5db9d84b0fd74ec67da155fada
> >Verifying Hash Integrity ... sha1+ OK
> > ## Loading fdt from FIT Image at 0200 ...
> >Using 'conf@1' configuration
> >Trying 'fdt@1' fdt subimage
> > Description: Flattened Device Tree blob
> > Type: Flat Device Tree
> > Compression: uncompressed
> > Data Start: 0x024d4de8
> > Data Size:16971 Bytes = 16.6 KiB
> > Architecture: ARM
> > Hash algo:sha1
> > Hash value: 672f2964b334406749265f4508e2231fb54ccbf4
> >Verifying Hash Integrity ... sha1+ OK
> >Booting using the fdt blob at 0x24d4de8
> >Loading Kernel Image ... OK
> >Loading Device Tree to 0fff8000, end 024a ... OK
> >
> > Starting kernel ...
> >
> >
> > Unfortunately v2016.09 is useless with this patch - at least for me.
> > I really think that we should revert it and release v2016.09.01.
> >
> > What do you think?
> >
> > Thanks,
> > Stefan
> > ___
> > 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 21/21] arm: imx: add i.MX6ULL 14x14 EVK board support
Hi Fabio,
On Wed, Sep 14, 2016 at 1:13 AM, Fabio Estevam wrote:
> Hi Jagan,
>
> On Tue, Sep 13, 2016 at 4:11 PM, Jagan Teki wrote:
>
> +int dram_init(void)
> +{
> + gd->ram_size = imx_ddr_size();
>>
>> Is this common call for all imx soc's to get the ddr size? because I
>> observed incorrect size when I call this function.
>
> Yes, if you get incorrect size when using this function, it means that
> your DDR initialization is incorrect.
OK, and I ran imx6 ddr calibration stress test[1] but observed data
abort. the objdump doesn't show any of these address, can you please
help me how can I proceed further?
icorem6qdl> fatload mmc 0:1 0x1000 ddr-stress-test-mx6dq.bin
reading ddr-stress-test-mx6dq.bin
87520 bytes read in 26 ms (3.2 MiB/s)
icorem6qdl> go 0x1000
## Starting application at 0x1000 ...
data abort
pc : [<00907060>] lr : [<8ff873fb>]
reloc pc : [<88182060>]lr : [<178023fb>]
sp : 8ef7c458 ip : 0010 fp : 0002
r10: 8ffb8914 r9 : 8ef84ee8 r8 : 8ef87cf0
r7 : 8ff873d1 r6 : 1000 r5 : 0002 r4 : 8ef87cf4
r3 : 1000 r2 : 8ef87cf4 r1 : 8ef87cf4 r0 : 0001
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
[1] https://community.nxp.com/docs/DOC-96412
thanks!
--
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: smsc95xx: fix DM MAC address reading
On Thu, Sep 15, 2016 at 1:53 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> eth-uclass.c expects DM-capable Ethernet adapters to implement ops->
> read_rom_hwaddr(), or for some other mechanism to set pdata->enetaddr, or
> for the user to set environment variable $usbethaddr. Without any of
> these, it will refuse to initialize the device since no valid MAC address
> is known. Implement this function for the smsc95xx driver.
>
> With this feature implemented, there is no point smsc95xx_init_common()
> re-reading the MAC address from ROM, so ifdef out this code when DM_ETH
> is enabled.
>
> This allows (at least) the built-in Ethernet on the NVIDIA Harmony board
> to operate again.
>
> Fixes: 0990fcb77219 ("net: smsc95xx: Add driver-model support")
> Signed-off-by: Stephen Warren
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/5] colibri_t20: fix display configuration
On 09/15/2016 01:27 AM, Marcel Ziswiler wrote: Without this patch the following error will be shown: stdio_add_devices: Video device failed (ret=-22) As commit ec5507707a1d1e84056a6c864338f95f6118d3ca (video: tegra: Move to using simple-panel and pwm-backlight) states the Colibri T20 needs updating too which this patch finally attempts doing. I haven't looked at this in any detail at all, but the one thing that stood out to me before is fixed, so, Acked-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/5] regulator: fixed: honour optionality of enable gpio
On 09/15/2016 03:30 AM, John Keeping wrote:
On Thu, 15 Sep 2016 09:27:22 +0200, Marcel Ziswiler wrote:
According to the binding documentation the fixed regulator enable GPIO
is optional. However so far registration thereof failed if no enable
GPIO was specified. Fix this by making it entirely optional whether an
enable GPIO is used.
@@ -98,8 +100,9 @@ static int fixed_regulator_set_enable(struct udevice *dev,
bool enable)
struct fixed_regulator_platdata *dev_pdata = dev_get_platdata(dev);
int ret;
+ /* Enable GPIO is optional */
if (!dev_pdata->gpio.dev)
- return -ENOSYS;
+ return 0;
I'm not sure about this change, the current behaviour seems correct to
me. After this we're pretending that fixed_set_enable(dev, false) has
succeeded, when it has not.
That should probably be:
if (!dev_pdata->gpio.dev) {
if (!enable)
return -ENOSYS
return 0;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: smsc95xx: fix DM MAC address reading
From: Stephen Warren
eth-uclass.c expects DM-capable Ethernet adapters to implement ops->
read_rom_hwaddr(), or for some other mechanism to set pdata->enetaddr, or
for the user to set environment variable $usbethaddr. Without any of
these, it will refuse to initialize the device since no valid MAC address
is known. Implement this function for the smsc95xx driver.
With this feature implemented, there is no point smsc95xx_init_common()
re-reading the MAC address from ROM, so ifdef out this code when DM_ETH
is enabled.
This allows (at least) the built-in Ethernet on the NVIDIA Harmony board
to operate again.
Fixes: 0990fcb77219 ("net: smsc95xx: Add driver-model support")
Signed-off-by: Stephen Warren
---
drivers/usb/eth/smsc95xx.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/eth/smsc95xx.c b/drivers/usb/eth/smsc95xx.c
index 7d9abfda3be1..d4c8ea4a98aa 100644
--- a/drivers/usb/eth/smsc95xx.c
+++ b/drivers/usb/eth/smsc95xx.c
@@ -519,9 +519,11 @@ static int smsc95xx_init_common(struct usb_device *udev,
struct ueth_data *dev,
debug("timeout waiting for PHY Reset\n");
return -ETIMEDOUT;
}
+#ifndef CONFIG_DM_ETH
if (!priv->have_hwaddr && smsc95xx_init_mac_address(enetaddr, udev) ==
0)
priv->have_hwaddr = 1;
+#endif
if (!priv->have_hwaddr) {
puts("Error: SMSC95xx: No MAC address set - set usbethaddr\n");
return -EADDRNOTAVAIL;
@@ -1022,6 +1024,19 @@ int smsc95xx_write_hwaddr(struct udevice *dev)
return smsc95xx_write_hwaddr_common(udev, priv, pdata->enetaddr);
}
+int smsc95xx_read_rom_hwaddr(struct udevice *dev)
+{
+ struct usb_device *udev = dev_get_parent_priv(dev);
+ struct eth_pdata *pdata = dev_get_platdata(dev);
+ int ret;
+
+ ret = smsc95xx_init_mac_address(pdata->enetaddr, udev);
+ if (ret)
+ memset(pdata->enetaddr, 0, 6);
+
+ return 0;
+}
+
static int smsc95xx_eth_probe(struct udevice *dev)
{
struct smsc95xx_private *priv = dev_get_priv(dev);
@@ -1037,6 +1052,7 @@ static const struct eth_ops smsc95xx_eth_ops = {
.free_pkt = smsc95xx_free_pkt,
.stop = smsc95xx_eth_stop,
.write_hwaddr = smsc95xx_write_hwaddr,
+ .read_rom_hwaddr = smsc95xx_read_rom_hwaddr,
};
U_BOOT_DRIVER(smsc95xx_eth) = {
--
2.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ARM: tegra: fix ULPI PHY on Ventana and Seaboard
From: Stephen Warren
Commit ce02a71c2374 "tegra: dts: Sync tegra20 device tree files with
Linux" enabled the ULPI USB port on Ventana, but made no attempt to ensure
that U-Boot code could handle this. In practice, various code is missing,
and various configuration options are not enabled, which causes U-Boot to
hang when attempting to initialize this USB port. This patch enables ULPI
PHY support on Ventana, and adds the required pinmux setup for the port to
operate. Note that Ventana is so similar to Seaboard that this change is
made in the Seaboard board file, which is shared with Ventana.
Seaboard also has the ULPI USB port wired up in hardware, although to an
internal port that often doesn't have anything attached to it. However,
the DT nodes for the USB controller and PHY had different status property
values, so the port was not initialized by U-Boot. Fix this inconsistency,
and enable the ULPI port, just like in the Linux kernel DT. This likewise
requires enabling ULPI support in the Seaboard defconfig.
Cc: Marcel Ziswiler
Signed-off-by: Stephen Warren
---
arch/arm/dts/tegra20-seaboard.dts | 2 +-
board/nvidia/seaboard/seaboard.c | 8 +++-
configs/seaboard_defconfig| 2 ++
configs/ventana_defconfig | 2 ++
4 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/tegra20-seaboard.dts
b/arch/arm/dts/tegra20-seaboard.dts
index 77f5bb51b027..341c7f35836a 100644
--- a/arch/arm/dts/tegra20-seaboard.dts
+++ b/arch/arm/dts/tegra20-seaboard.dts
@@ -784,7 +784,7 @@
};
usb@c5004000 {
- status = "disabled";
+ status = "okay";
nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1)
GPIO_ACTIVE_LOW>;
};
diff --git a/board/nvidia/seaboard/seaboard.c b/board/nvidia/seaboard/seaboard.c
index fc9c1c9b34dc..4e01deb02fb0 100644
--- a/board/nvidia/seaboard/seaboard.c
+++ b/board/nvidia/seaboard/seaboard.c
@@ -44,6 +44,12 @@ void pin_mux_mmc(void)
void pin_mux_usb(void)
{
- /* For USB's GPIO PD0. For now, since we have no pinmux in fdt */
+ /* For USB0's GPIO PD0. For now, since we have no pinmux in fdt */
pinmux_tristate_disable(PMUX_PINGRP_SLXK);
+ /* For USB1's ULPI signals */
+ funcmux_select(PERIPH_ID_USB2, FUNCMUX_USB2_ULPI);
+ pinmux_set_func(PMUX_PINGRP_CDEV2, PMUX_FUNC_PLLP_OUT4);
+ pinmux_tristate_disable(PMUX_PINGRP_CDEV2);
+ /* USB1 PHY reset GPIO */
+ pinmux_tristate_disable(PMUX_PINGRP_UAC);
}
diff --git a/configs/seaboard_defconfig b/configs/seaboard_defconfig
index 12cc9b62e7fe..806caca1226a 100644
--- a/configs/seaboard_defconfig
+++ b/configs/seaboard_defconfig
@@ -35,6 +35,8 @@ CONFIG_PWM_TEGRA=y
CONFIG_SYS_NS16550=y
CONFIG_USB=y
CONFIG_DM_USB=y
+CONFIG_USB_ULPI_VIEWPORT=y
+CONFIG_USB_ULPI=y
CONFIG_USB_STORAGE=y
CONFIG_DM_VIDEO=y
CONFIG_VIDEO_TEGRA20=y
diff --git a/configs/ventana_defconfig b/configs/ventana_defconfig
index 8288c860067b..56e7ba367d60 100644
--- a/configs/ventana_defconfig
+++ b/configs/ventana_defconfig
@@ -34,6 +34,8 @@ CONFIG_PWM_TEGRA=y
CONFIG_SYS_NS16550=y
CONFIG_USB=y
CONFIG_DM_USB=y
+CONFIG_USB_ULPI_VIEWPORT=y
+CONFIG_USB_ULPI=y
CONFIG_USB_STORAGE=y
CONFIG_DM_VIDEO=y
CONFIG_VIDEO_TEGRA20=y
--
2.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ARM: tegra: fix USB ULPI PHY reset signal inversion confusion
From: Stephen Warren
USB ULPI PHY reset signals are typically active low. Consequently, they
should be marked as GPIO_ACTIVE_LOW in device tree, and indeed they are in
the Linux kernel DTs, and in DT properties that U-Boot doesn't yet use.
However, in DT properties that U-Boot does use, the value has been set to
0 (== GPIO_ACTIVE_HIGH) to work around a bug in U-Boot.
This change fixes the DT to correctly represent the HW, and fixes the
Tegra USB driver to cope with the fact that dm_gpio_set_value() internally
handles any inversions implied by the DT value GPIO_ACTIVE_LOW.
Cc: Marcel Ziswiler
Signed-off-by: Stephen Warren
---
arch/arm/dts/tegra20-colibri.dts | 3 ++-
arch/arm/dts/tegra20-harmony.dts | 3 ++-
drivers/usb/host/ehci-tegra.c| 13 +++--
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/tegra20-colibri.dts b/arch/arm/dts/tegra20-colibri.dts
index a291d93c7d01..777f63e5bdb6 100644
--- a/arch/arm/dts/tegra20-colibri.dts
+++ b/arch/arm/dts/tegra20-colibri.dts
@@ -39,7 +39,8 @@
usb@c5004000 {
statuc = "okay";
/* VBUS_LAN */
- nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1)
GPIO_ACTIVE_HIGH>;
+ nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1)
+ GPIO_ACTIVE_LOW>;
nvidia,vbus-gpio = <&gpio TEGRA_GPIO(BB, 1) GPIO_ACTIVE_HIGH>;
};
diff --git a/arch/arm/dts/tegra20-harmony.dts b/arch/arm/dts/tegra20-harmony.dts
index cace74339483..5aec150b5e61 100644
--- a/arch/arm/dts/tegra20-harmony.dts
+++ b/arch/arm/dts/tegra20-harmony.dts
@@ -626,7 +626,8 @@
usb@c5004000 {
status = "okay";
- nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1) 0>;
+ nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1)
+ GPIO_ACTIVE_LOW>;
};
usb-phy@c5004000 {
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index 31d54ab285bf..c10597861873 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -600,9 +600,18 @@ static int init_ulpi_usb_controller(struct fdt_usb *config,
/* reset ULPI phy */
if (dm_gpio_is_valid(&config->phy_reset_gpio)) {
- dm_gpio_set_value(&config->phy_reset_gpio, 0);
- mdelay(5);
+ /*
+* This GPIO is typically active-low, and marked as such in
+* device tree. dm_gpio_set_value() takes this into account
+* and inverts the value we pass here if required. In other
+* words, this first call logically asserts the reset signal,
+* which typically results in driving the physical GPIO low,
+* and the second call logically de-asserts the reset signal,
+* which typically results in driver the GPIO high.
+*/
dm_gpio_set_value(&config->phy_reset_gpio, 1);
+ mdelay(5);
+ dm_gpio_set_value(&config->phy_reset_gpio, 0);
}
/* Reset the usb controller */
--
2.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] ARM: tegra: fix USB controller aliases
From: Stephen Warren
Some boards have a different set of USB controllers enabled in DT than
the set referenced by /alias entries. This patch fixes that. For
example, this avoids the following message while booting on Ventana,
which is caused by the fact that the USB0 controller had no alias, and
defaulted to wanting a sequence number of 0, which was later explicitly
requested by the alias for USB controller 2.
USB2: Device 'usb@c5008000': seq 0 is in use by 'usb@c500'
This didn't affect USB operation in any way though.
Related, there's no need for the USB controller aliases to have an order
that's different from the HW order, so re-order any aliases to match the
HW ordering. This has the benefit that since USB controller 0 is the only
one that supports device-mode in HW, and U-Boot only supports enabling
device move on controller 0, there's now good synergy in the ordering! For
Tegra20, that's not relevant at present since USB device mode doesn't work
correctly on that SoC, but it will save some head-scratching later.
This patch doesn't fix the colibri_t20 board, even though it has the same
issue, since Marcel already sent a patch for that.
Cc: Marcel Ziswiler
Signed-off-by: Stephen Warren
---
arch/arm/dts/tegra20-harmony.dts | 3 ++-
arch/arm/dts/tegra20-seaboard.dts | 5 +++--
arch/arm/dts/tegra20-trimslice.dts | 3 +--
arch/arm/dts/tegra20-ventana.dts | 4 +++-
4 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/tegra20-harmony.dts b/arch/arm/dts/tegra20-harmony.dts
index 5aec150b5e61..dcbde7c2ed7e 100644
--- a/arch/arm/dts/tegra20-harmony.dts
+++ b/arch/arm/dts/tegra20-harmony.dts
@@ -15,8 +15,9 @@
rtc0 = "/i2c@7000d000/tps6586x@34";
rtc1 = "/rtc@7000e000";
serial0 = &uartd;
- usb0 = "/usb@c5008000";
+ usb0 = "/usb@c500";
usb1 = "/usb@c5004000";
+ usb2 = "/usb@c5008000";
mmc0 = "/sdhci@c8000600";
mmc1 = "/sdhci@c8000200";
};
diff --git a/arch/arm/dts/tegra20-seaboard.dts
b/arch/arm/dts/tegra20-seaboard.dts
index 14210519a6c2..77f5bb51b027 100644
--- a/arch/arm/dts/tegra20-seaboard.dts
+++ b/arch/arm/dts/tegra20-seaboard.dts
@@ -9,8 +9,9 @@
aliases {
/* This defines the order of our ports */
- usb0 = "/usb@c5008000";
- usb1 = "/usb@c500";
+ usb0 = "/usb@c500";
+ usb1 = "/usb@c5004000";
+ usb2 = "/usb@c5008000";
i2c0 = "/i2c@7000d000";
i2c1 = "/i2c@7000c000";
i2c2 = "/i2c@7000c400";
diff --git a/arch/arm/dts/tegra20-trimslice.dts
b/arch/arm/dts/tegra20-trimslice.dts
index be64e667cd5b..7fb7dd0b5815 100644
--- a/arch/arm/dts/tegra20-trimslice.dts
+++ b/arch/arm/dts/tegra20-trimslice.dts
@@ -11,8 +11,7 @@
};
aliases {
- usb0 = "/usb@c5008000";
- usb1 = "/usb@c500";
+ usb0 = "/usb@c500";
mmc0 = "/sdhci@c8000600";
mmc1 = "/sdhci@c800";
spi0 = "/spi@7000c380";
diff --git a/arch/arm/dts/tegra20-ventana.dts b/arch/arm/dts/tegra20-ventana.dts
index 371445622c1e..85cd1e39bda7 100644
--- a/arch/arm/dts/tegra20-ventana.dts
+++ b/arch/arm/dts/tegra20-ventana.dts
@@ -15,7 +15,9 @@
rtc0 = "/i2c@7000d000/tps6586x@34";
rtc1 = "/rtc@7000e000";
serial0 = &uartd;
- usb0 = "/usb@c5008000";
+ usb0 = "/usb@c500";
+ usb1 = "/usb@c5004000";
+ usb2 = "/usb@c5008000";
mmc0 = "/sdhci@c8000600";
mmc1 = "/sdhci@c8000400";
};
--
2.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] apalis_t30: colibri_imx7: colibri_t30: fix ethernet functionality
On Wed, Sep 14, 2016 at 5:54 PM, Marcel Ziswiler
wrote:
> Since commit aa7a648747d8c704a9a81c9e493d386930724e9d
> ("net: Stop including NFS overhead in defragment max") the following
> has been reproducibly observed while trying to transfer data over TFTP:
>
> Load address: 0x80408000
> Loading: EHCI timed out on TD - token=0x8008d80
> T EHCI timed out on TD - token=0x88008d80
> Rx: failed to receive: -5
>
> This patch fixes this by lowering our TFTP block size to be within the
> standard maximal de-fragmentation aka IP packet size again.
>
> Signed-off-by: Marcel Ziswiler
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot memory allocation problems with ast2500
Hi Maxim, On 14 September 2016 at 09:50, Maxim Sloyko wrote: > > > > On Fri, Sep 9, 2016 at 4:18 PM, Simon Glass wrote: >> >> Hi Maxim, >> >> On 9 September 2016 at 15:53, Maxim Sloyko wrote: >> > >> > Hi all, >> > >> > First, disclaimer: this is the first time I'm doing something with U-Boot >> > or the part (ast2500), so any claim I make below can be false or just >> > plain nonsense. >> >> Welcome! >> >> > >> > I'm working on expanding support of Aspeed ast2500 part in U-Boot. >> > >> > I ran into some problems, when I tried to use Linux Kernel device tree for >> > this part in U-Boot. Looking at diagnostic messages >> > (http://pastebin.ca/3713876) I figured out that the problem is that U-Boot >> > continues to use malloc_simple, even after it has been relocated to RAM. >> > As a result, it fails to allocate 130k needed for environment, because it >> > is larger than the configured size of a memory chunk for simple malloc. >> >> The test for this is in dlmalloc.c - the GD_FLG_FULL_MALLOC_INIT flag. >> The flag is set in initr_reloc() after relocation. >> >> I wonder if your global_data (the 'gd' pointer) is not set up >> correctly, so it cannot write to the flag. > > > OK, so you are right, this flag turned out to be a problem. Global data was > setup normally, but then for some reason in board_init there was a line > > gd->flags = 0; > > I removed it and everything works now. > > Thanks for your help! OK, that's good! [...] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] does it make sense to define misc_init_r() not conditional on CONFIG_MISC_INIT_R?
Hi Robert,
On 14 September 2016 at 07:16, Robert P. J. Day wrote:
>
> another oddity i noted in my travels ... in common/board_r.c, this:
>
> #ifdef CONFIG_MISC_INIT_R
> misc_init_r,/* miscellaneous platform-dependent init */
> #endif
>
> suggests that any *definition* of a board's misc_init_r() routine
> should be similarly conditional, but there are well over a hundred
> counter-examples like, say, this from km83xx.c:
>
> int misc_init_r(void)
> {
> ivm_read_eeprom(ivm_content, CONFIG_SYS_IVM_EEPROM_MAX_LEN);
> return 0;
> }
>
> doesn't hurt, of course ... binary just ends up containing a
> superfluous misc_init_r() routine that's never called. i suspect
> there's a lot of that with other routines as well.
>
> or is there something else going on here more subtle that i don't
> understand?
Typically the board will define CONFIG_MISC_INIT_R and also provide
the function. The board won't work properly without it. There is a
linkage between the config and the code.
So I don't see any sense in adding #ifdef around the function, if that
is what you are suggesting? But having the function present and not
called does seem odd.
As time moves on and things move to driver model, I suspect a lot of
this init will be turned down.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] image-fit: switch ENOLINK to ENOENT
Hi Stefan,
I also see the same error on our Armada board. It stems from the fact that
boot_get_ramdisk in common/image.c treats a ENOLINK different from all other
errors (which the patch changed into a ENOENT). The following patch fixes the
problem on our board:
diff --git a/common/image.c b/common/image.c
index 7ad04ca..c8d9bc8 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1078,7 +1078,7 @@ int boot_get_ramdisk(int argc, char * const
argv[], bootm_headers_t *images,
rd_addr = map_to_sysmem(images->fit_hdr_os);
rd_noffset = fit_get_node_from_config(images,
FIT_RAMDISK_PROP, rd_addr);
-if (rd_noffset == -ENOLINK)
+if (rd_noffset == -ENOENT)
return 0;
else if (rd_noffset < 0)
return 1;
So, yes, 2016.09 breaks Armada, apparently.
Best regards,
Mario
On Thu, Sep 15, 2016 at 2:49 PM, Stefan Roese wrote:
> Hi Tom,
> Hi Jonathan,
>
> On 03.09.2016 00:30, Jonathan Gray wrote:
>> ENOLINK is not required by POSIX and does not exist on OpenBSD
>> and likely other systems.
>>
>> Signed-off-by: Jonathan Gray
>> ---
>> common/image-fit.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/common/image-fit.c b/common/image-fit.c
>> index d8d4e95..79c0375 100644
>> --- a/common/image-fit.c
>> +++ b/common/image-fit.c
>> @@ -1566,7 +1566,7 @@ int fit_get_node_from_config(bootm_headers_t *images,
>> const char *prop_name,
>> noffset = fit_conf_get_prop_node(fit_hdr, cfg_noffset, prop_name);
>> if (noffset < 0) {
>> debug("* %s: no '%s' in config\n", prop_name, prop_name);
>> - return -ENOLINK;
>> + return -ENOENT;
>> }
>>
>> return noffset;
>>
>
> This patch breaks Linux booting via FIT-image on Marvell Armada
> XP for me. Here a short log with this patch applied:
>
> ## Loading kernel from FIT Image at 0200 ...
>Using 'conf@1' configuration
>Trying 'kernel@1' kernel subimage
> Description: Linux kernel
> Type: Kernel Image
> Compression: uncompressed
> Data Start: 0x02f4
> Data Size:5065728 Bytes = 4.8 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x8000
> Entry Point: 0x8000
> Hash algo:sha1
> Hash value: 11ddefa0b68cbc5db9d84b0fd74ec67da155fada
>Verifying Hash Integrity ... sha1+ OK
> Ramdisk image is corrupt or invalid
>
>
> And this is how is should look like:
>
> ## Loading kernel from FIT Image at 0200 ...
>Using 'conf@1' configuration
>Trying 'kernel@1' kernel subimage
> Description: Linux kernel
> Type: Kernel Image
> Compression: uncompressed
> Data Start: 0x02f4
> Data Size:5065728 Bytes = 4.8 MiB
> Architecture: ARM
> OS: Linux
> Load Address: 0x8000
> Entry Point: 0x8000
> Hash algo:sha1
> Hash value: 11ddefa0b68cbc5db9d84b0fd74ec67da155fada
>Verifying Hash Integrity ... sha1+ OK
> ## Loading fdt from FIT Image at 0200 ...
>Using 'conf@1' configuration
>Trying 'fdt@1' fdt subimage
> Description: Flattened Device Tree blob
> Type: Flat Device Tree
> Compression: uncompressed
> Data Start: 0x024d4de8
> Data Size:16971 Bytes = 16.6 KiB
> Architecture: ARM
> Hash algo:sha1
> Hash value: 672f2964b334406749265f4508e2231fb54ccbf4
>Verifying Hash Integrity ... sha1+ OK
>Booting using the fdt blob at 0x24d4de8
>Loading Kernel Image ... OK
>Loading Device Tree to 0fff8000, end 024a ... OK
>
> Starting kernel ...
>
>
> Unfortunately v2016.09 is useless with this patch - at least for me.
> I really think that we should revert it and release v2016.09.01.
>
> What do you think?
>
> Thanks,
> Stefan
> ___
> 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
[U-Boot] [PATCH] keystone2: k2g: add env script to load firmware initramfs as part of boot flow
From: Murali Karicheri
On K2G, the PCIe SerDes h/w is a re-use from other K2 devices and SerDes
driver requires a firmware image to initialize the SerDes h/w device.
This is firmware is part of the initramfs file that is loaded to memory
in u-boot and passed to kernel as in other K2 platforms. This patch
customize the u-boot env to have this done automatically when the K2G EVM
boots up. With this, a user may be able to boot the EVM with a standard
PCIe card at the x1 PCIe slot and release image and test PCIe devices
such as NIC, SATA etc.
Signed-off-by: Murali Karicheri
Signed-off-by: Lokesh Vutla
---
include/configs/k2g_evm.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
index 71b0037..d73543f 100644
--- a/include/configs/k2g_evm.h
+++ b/include/configs/k2g_evm.h
@@ -18,6 +18,7 @@
#define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\
DEFAULT_MMC_TI_ARGS \
DEFAULT_PMMC_BOOT_ENV \
+ DEFAULT_FW_INITRAMFS_BOOT_ENV \
"boot=mmc\0"\
"console=ttyS0,115200n8\0" \
"bootpart=0:2\0"\
@@ -31,6 +32,8 @@
"name_ubi=k2g-evm-ubifs.ubi\0" \
"name_uboot=u-boot-spi-k2g-evm.gph\0" \
"init_mmc=run args_all args_mmc\0" \
+ "init_fw_rd_mmc=load mmc ${bootpart} ${rdaddr} "\
+ "${bootdir}/${name_fw_rd}; run set_rd_spec\0" \
"soc_variant=k2g\0" \
"get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}\0"\
"get_kern_mmc=load mmc ${bootpart} ${loadaddr} "\
@@ -40,7 +43,8 @@
#define CONFIG_BOOTCOMMAND \
"run envboot; " \
- "run set_name_pmmc init_${boot} get_pmmc_${boot} run_pmmc " \
+ "run set_name_pmmc init_${boot} init_fw_rd_${boot} "\
+ "get_pmmc_${boot} run_pmmc "\
"get_fdt_${boot} get_mon_${boot} get_kern_${boot} " \
"run_mon run_kern"
--
2.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [bug report] sunxi: booting from eMMC
Hi, On Wed, Sep 14, 2016 at 12:05:19PM +0200, Hans de Goede wrote: > Hi, > > On 13-09-16 13:50, Maxime Ripard wrote: > >Hi, > > > >On Mon, Sep 12, 2016 at 04:47:49PM +0200, Hans de Goede wrote: > >>On 12-09-16 15:56, Maxime Ripard wrote: > >>>Hi, > >>> > >>>On Mon, Sep 12, 2016 at 01:53:24PM +0200, Ciprian Manea wrote: > I'm using a SinA33 dev board (Allwinner a33 SoC) and at the moment > I'm trying to boot from the eMMC. > > But it fails in the following way: > > > *Got the following error at boot time:* > *U-Boot SPL 2016.09-rc2-00125-g6e8b42f (Sep 08 2016 - 11:00:46) DRAM: 1024 > MiB Trying to boot from MMC2 MMC Device 1 not found spl: could not find > mmc > device. error: -19 SPL: failed to boot from all boot devices ### ERROR ### > Please RESET the board ###* > >>> > >>>So I've been on the same issue for the last couple of days. > >>> > >>>Since that board is already supported, adding support for the eMMC > >>>basically came down to that patch on top of 2016.09-rc2. > >>> > >>>http://code.bulix.org/kcgxri-106037?raw > >>> > >>>(Quite hackish, the 8-Bits part being a separate issue that would need > >>>to be addressed somehow). > >>> > >>>However, it doesn't work, neither when flashing u-boot on the eMMC > >>>itself (where there's a timeout error in the SPL) nor when trying to > >>>access the eMMC from a U-Boot loaded from the (external) SD. > >>> > >>>In the latter case, even mmc dev 1 fails silently. > >>> > >>>I traced that down to the mmc_switch here: > >>>http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/mmc.c#l530 > >>> > >>>Which fails with ETIMEDOUT, and more specifically, it's the call to > >>>mmc_rint_wait here > >>>http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/sunxi_mmc.c#l383 > >>>that times out. > >>> > >>>Increasing the timeout value (to 1) doesn't really change > >>>anything. I guess this is also the reason why we had a timeout error > >>>in the SPL. > >>> > >>>This eMMC works fine in Linux, with the same muxing (and I guess the > >>>earlier commands wouldn't be successful if the muxing or power was not > >>>set up appropriately). So I'm kind of running out of ideas on what > >>>could be the root cause of this. > >>> > >>>Hans, any ideas? > >> > >>Maybe the emmc needs external pull-ups ? I don't remember if u-boot > >>always enables those or not ... > > > >So I pushed this a bit more, and it seems like commenting the call to > >mmc_change_freq makes everything just work. > > > >Reading the JEDEC spec, it looks like when you switch to high speed, > >you also need to change the controller clock rate, that u-boot doesn't > >seem to do at the moment, which obviously will fail, since the > >controller will be stuck at the former rate, while the eMMC would be > >switched. > > > >If I comment mmc_change_freq, everything works. > > Hmm, I'm pretty sure the u-boot sunxi mmc code > does properly change the clock, see mmc_set_mod_clk() in > drivers/mmc/sunxi_mmc.c > > This will switch to the right PLL, etc. So there likely is > something else going on making things not work at higher > speeds. Maybe we need a higher driver strenghts at the > mmc io pins, or maybe we've a completely unrelated issue ? > > I'm pretty sure that the eMMC's on A20 devices work fine > in 50MHZ (SDR) mode. Yeah, sorry, I was missing the mmc_set_clock call in that function, that ends up calling mmc_set_mod_clk. I'll look more into it, it might be just a matter of phases to adjust. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] image-fit: switch ENOLINK to ENOENT
Hi Tom,
Hi Jonathan,
On 03.09.2016 00:30, Jonathan Gray wrote:
> ENOLINK is not required by POSIX and does not exist on OpenBSD
> and likely other systems.
>
> Signed-off-by: Jonathan Gray
> ---
> common/image-fit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/image-fit.c b/common/image-fit.c
> index d8d4e95..79c0375 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -1566,7 +1566,7 @@ int fit_get_node_from_config(bootm_headers_t *images,
> const char *prop_name,
> noffset = fit_conf_get_prop_node(fit_hdr, cfg_noffset, prop_name);
> if (noffset < 0) {
> debug("* %s: no '%s' in config\n", prop_name, prop_name);
> - return -ENOLINK;
> + return -ENOENT;
> }
>
> return noffset;
>
This patch breaks Linux booting via FIT-image on Marvell Armada
XP for me. Here a short log with this patch applied:
## Loading kernel from FIT Image at 0200 ...
Using 'conf@1' configuration
Trying 'kernel@1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x02f4
Data Size:5065728 Bytes = 4.8 MiB
Architecture: ARM
OS: Linux
Load Address: 0x8000
Entry Point: 0x8000
Hash algo:sha1
Hash value: 11ddefa0b68cbc5db9d84b0fd74ec67da155fada
Verifying Hash Integrity ... sha1+ OK
Ramdisk image is corrupt or invalid
And this is how is should look like:
## Loading kernel from FIT Image at 0200 ...
Using 'conf@1' configuration
Trying 'kernel@1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x02f4
Data Size:5065728 Bytes = 4.8 MiB
Architecture: ARM
OS: Linux
Load Address: 0x8000
Entry Point: 0x8000
Hash algo:sha1
Hash value: 11ddefa0b68cbc5db9d84b0fd74ec67da155fada
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 0200 ...
Using 'conf@1' configuration
Trying 'fdt@1' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x024d4de8
Data Size:16971 Bytes = 16.6 KiB
Architecture: ARM
Hash algo:sha1
Hash value: 672f2964b334406749265f4508e2231fb54ccbf4
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x24d4de8
Loading Kernel Image ... OK
Loading Device Tree to 0fff8000, end 024a ... OK
Starting kernel ...
Unfortunately v2016.09 is useless with this patch - at least for me.
I really think that we should revert it and release v2016.09.01.
What do you think?
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Add sdram capacity auto detect for rk3288
Hi Kever, With regards to the SPL size issue, I believe that the CONFIG_ROCKCHIP_SPL_BACK_TO_BROM option should work with all of the rk3288 boards. So if your patch causes unbootable SPL's because they're too big, then you should probably enable the BROM macro (and disable OF_PLATDATA). Firefly uses a different method to shrink the SPL which causes a bunch of changes throughout the codebase. This patch would need to be applied to the OF_PLATDATA sections for firefly to work. Vagrant, An alternative for you might be to disable OF_PLATDATA for firefly and enable BACK_TO_BROM. You may not be getting any output because you didn't modify your burning process. See the README.rockchip section on CONFIG_ROCKCHIP_SPL_BACK_TO_BROM for details, but you have to dd your images slightly differently with this macro enabled. Also, you might get more info from Ziyuan's DEBUG advice. Sandy Patterson On Sun, Sep 11, 2016 at 10:01 PM, Ziyuan Xu wrote: > hi Vagrant, > > > > On 2016年09月11日 03:01, Vagrant Cascadian wrote: > >> On 2016-09-10, Ziyuan Xu wrote: >> >>> On 2016年09月09日 03:28, Vagrant Cascadian wrote: >>> On 2016-09-08, Kever Yang wrote: > The rk3288 spl size is very close to 32KB while the rk3288 bootrom > has the limitation of maximum size of SPL is 32KB. After apply this > patch, the SPL size will exceed 32KB if we do not enable macro > CONFIG_ROCKCHIP_SPL_BACK_TO_BROM. > With CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y, it fails to boot with no >> output >> on the console. >> >> >> This patch has test with 2GB DDR3 and 2GB/4GB LPDDR3. > Thanks for the patch! Unfortunately, fails to build the firefly-rk3288 target, using arm-linux-gnueabihf-gcc (Debian 6.1.1-9) 6.1.1 20160705, applied to u-boot master 01c5075506afcb7a74e0db8600af8979f45881b5: CC spl/arch/arm/mach-rockchip/rk3288/sdram_rk3288.o arch/arm/mach-rockchip/rk3288/sdram_rk3288.c: In function 'conv_of_platdata': arch/arm/mach-rockchip/rk3288/sdram_rk3288.c:1042:30: error: 'struct dtd_rockchip_rk3288_dmc' has no member named 'rockchip_num_channels'; did you mean 'rockchip_noc'? plat->num_channels = of_plat->rockchip_num_channels; >>> - plat->num_channels = of_plat->rockchip_num_channels; >>> + plat->num_channels = 2; >>> >>> firefly-rk3288 deploy CONFIG_OF_PLATDATA, driver read platform data >>> from include/generated/dt-structs.h which is generated according to dts >>> file. >>> Please try above change. >>> >> With this change, it builds, but it hangs at boot: >> >>U-Boot SPL 2016.09-rc2+dfsg1-2~20160910~6 (Sep 10 2016 - 18:51:28) >>Trying to boot from MMC1 >> >> >>U-Boot 2016.09-rc2+dfsg1-2~20160910~6 (Sep 10 2016 - 18:51:28 +) >> >>Model: Firefly-RK3288 >>DRAM: >> > > Could you help to add DEBUG macro in common.h like: > #indef CONFIG_SPL_BUILD > #define DEBUG > #endif > > So that we can figure out where it is. > > > >> This is on a firefly with 2GB of ram. I also have one with 4GB of ram, >> hence my interest in this patch series! >> >> >> live well, >>vagrant >> > > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] power: regulator: Add support for gpio regulators
On Thursday 15 September 2016 05:12 PM, Przemyslaw Marczak wrote:
On 09/15/2016 12:34 PM, Keerthy wrote:
On Thursday 15 September 2016 03:04 PM, Przemyslaw Marczak wrote:
Hello Keerthy,
On 09/15/2016 10:25 AM, Keerthy wrote:
Add support for gpio regulators. As of now this driver caters
to gpio regulators with one gpio. Supports setting voltage values to
gpio
regulators and retrieving the values.
Signed-off-by: Keerthy
---
drivers/power/regulator/Kconfig | 8 ++
drivers/power/regulator/Makefile | 1 +
drivers/power/regulator/gpio-regulator.c | 136
+++
include/power/regulator.h| 1 +
4 files changed, 146 insertions(+)
create mode 100644 drivers/power/regulator/gpio-regulator.c
diff --git a/drivers/power/regulator/Kconfig
b/drivers/power/regulator/Kconfig
index 2510474..4776011 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -58,6 +58,14 @@ config DM_REGULATOR_FIXED
features for fixed value regulators. The driver implements
get/set api
for enable and get only for voltage value.
+config DM_REGULATOR_GPIO
+bool "Enable Driver Model for GPIO REGULATOR"
+depends on DM_REGULATOR
+---help---
+This config enables implementation of driver-model regulator
uclass
+features for gpio regulators. The driver implements get/set for
+voltage value.
+
config REGULATOR_RK808
bool "Enable driver for RK808 regulators"
depends on DM_REGULATOR && PMIC_RK808
diff --git a/drivers/power/regulator/Makefile
b/drivers/power/regulator/Makefile
index 2093048..2d350cb 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_RK808) += rk808.o
obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
diff --git a/drivers/power/regulator/gpio-regulator.c
b/drivers/power/regulator/gpio-regulator.c
new file mode 100644
index 000..9c8832e
--- /dev/null
+++ b/drivers/power/regulator/gpio-regulator.c
@@ -0,0 +1,136 @@
+/*
+ * (C) Copyright 2016 Texas Instruments Incorporated,
+ * Keerthy
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct gpio_regulator_platdata {
+struct gpio_desc gpio; /* GPIO for regulator voltage control */
+int gpio_low_uV;
+int gpio_high_uV;
+};
The low/high values can be provided by regulator's uclass driver in
struct of type "dm_regulator_uclass_platdata", as for other regulators.
min_uV, max_uV represent the minimum and maximum voltages in
dm_regulator_uclass_platdata. I would not use them here.
Ah right, sorry I just get wrong the name of those variables above - as
min/max uV, but your point was about the GPIO lo/hi state.
But as I can see in the Linux, this driver should provide a structure
for the gpio states.
Yes so i am keeping the voltage values for 0 and 1 states in a driver
specific struct.
+
+static int gpio_regulator_ofdata_to_platdata(struct udevice *dev)
+{
+struct dm_regulator_uclass_platdata *uc_pdata;
+struct gpio_regulator_platdata *dev_pdata;
+struct gpio_desc *gpio;
+const void *blob = gd->fdt_blob;
+int node = dev->of_offset;
+int ret, count, i;
+u32 states_array[8];
+
+dev_pdata = dev_get_platdata(dev);
+uc_pdata = dev_get_uclass_platdata(dev);
+if (!uc_pdata)
+return -ENXIO;
+
+/* Set type to gpio */
+uc_pdata->type = REGULATOR_TYPE_GPIO;
+
+/*
+ * Get gpio regulator gpio desc
+ * Assuming one GPIO per regulator.
+ * Can be extended later to multiple GPIOs
+ * per gpio-regulator. As of now no instance with multiple
+ * gpios is presnt
+ */
+gpio = &dev_pdata->gpio;
+ret = gpio_request_by_name(dev, "gpios", 0, gpio, GPIOD_IS_OUT);
+if (ret)
+debug("regulator gpio - not found! Error: %d", ret);
+
+count = fdtdec_get_int_array_count(blob, node, "states",
+ states_array, 8);
+
+if (!count)
+return -EINVAL;
+
+for (i = 0; i < count; i += 2) {
The below condition is valid for most devices.
In Linux we can find dts for some ARMs in which I can find at least two
boards,
with inverted meaning of state/voltage, so "0", can be also valid for
the high uV.
I think, this driver should keep possible states in platdata.
Okay. I get the point. So i will have both states and corresponding
states voltages stored in gpio_regulator_platdata structure and set
states corresponding to requested voltages.
Yes, so actually the only issue is low/high interpretation.
Maybe the
Re: [U-Boot] [PATCH] power: regulator: Add support for gpio regulators
On 09/15/2016 12:34 PM, Keerthy wrote:
On Thursday 15 September 2016 03:04 PM, Przemyslaw Marczak wrote:
Hello Keerthy,
On 09/15/2016 10:25 AM, Keerthy wrote:
Add support for gpio regulators. As of now this driver caters
to gpio regulators with one gpio. Supports setting voltage values to
gpio
regulators and retrieving the values.
Signed-off-by: Keerthy
---
drivers/power/regulator/Kconfig | 8 ++
drivers/power/regulator/Makefile | 1 +
drivers/power/regulator/gpio-regulator.c | 136
+++
include/power/regulator.h| 1 +
4 files changed, 146 insertions(+)
create mode 100644 drivers/power/regulator/gpio-regulator.c
diff --git a/drivers/power/regulator/Kconfig
b/drivers/power/regulator/Kconfig
index 2510474..4776011 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -58,6 +58,14 @@ config DM_REGULATOR_FIXED
features for fixed value regulators. The driver implements
get/set api
for enable and get only for voltage value.
+config DM_REGULATOR_GPIO
+bool "Enable Driver Model for GPIO REGULATOR"
+depends on DM_REGULATOR
+---help---
+This config enables implementation of driver-model regulator
uclass
+features for gpio regulators. The driver implements get/set for
+voltage value.
+
config REGULATOR_RK808
bool "Enable driver for RK808 regulators"
depends on DM_REGULATOR && PMIC_RK808
diff --git a/drivers/power/regulator/Makefile
b/drivers/power/regulator/Makefile
index 2093048..2d350cb 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_RK808) += rk808.o
obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
diff --git a/drivers/power/regulator/gpio-regulator.c
b/drivers/power/regulator/gpio-regulator.c
new file mode 100644
index 000..9c8832e
--- /dev/null
+++ b/drivers/power/regulator/gpio-regulator.c
@@ -0,0 +1,136 @@
+/*
+ * (C) Copyright 2016 Texas Instruments Incorporated,
+ * Keerthy
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct gpio_regulator_platdata {
+struct gpio_desc gpio; /* GPIO for regulator voltage control */
+int gpio_low_uV;
+int gpio_high_uV;
+};
The low/high values can be provided by regulator's uclass driver in
struct of type "dm_regulator_uclass_platdata", as for other regulators.
min_uV, max_uV represent the minimum and maximum voltages in
dm_regulator_uclass_platdata. I would not use them here.
Ah right, sorry I just get wrong the name of those variables above - as
min/max uV, but your point was about the GPIO lo/hi state.
But as I can see in the Linux, this driver should provide a structure
for the gpio states.
Yes so i am keeping the voltage values for 0 and 1 states in a driver
specific struct.
+
+static int gpio_regulator_ofdata_to_platdata(struct udevice *dev)
+{
+struct dm_regulator_uclass_platdata *uc_pdata;
+struct gpio_regulator_platdata *dev_pdata;
+struct gpio_desc *gpio;
+const void *blob = gd->fdt_blob;
+int node = dev->of_offset;
+int ret, count, i;
+u32 states_array[8];
+
+dev_pdata = dev_get_platdata(dev);
+uc_pdata = dev_get_uclass_platdata(dev);
+if (!uc_pdata)
+return -ENXIO;
+
+/* Set type to gpio */
+uc_pdata->type = REGULATOR_TYPE_GPIO;
+
+/*
+ * Get gpio regulator gpio desc
+ * Assuming one GPIO per regulator.
+ * Can be extended later to multiple GPIOs
+ * per gpio-regulator. As of now no instance with multiple
+ * gpios is presnt
+ */
+gpio = &dev_pdata->gpio;
+ret = gpio_request_by_name(dev, "gpios", 0, gpio, GPIOD_IS_OUT);
+if (ret)
+debug("regulator gpio - not found! Error: %d", ret);
+
+count = fdtdec_get_int_array_count(blob, node, "states",
+ states_array, 8);
+
+if (!count)
+return -EINVAL;
+
+for (i = 0; i < count; i += 2) {
The below condition is valid for most devices.
In Linux we can find dts for some ARMs in which I can find at least two
boards,
with inverted meaning of state/voltage, so "0", can be also valid for
the high uV.
I think, this driver should keep possible states in platdata.
Okay. I get the point. So i will have both states and corresponding
states voltages stored in gpio_regulator_platdata structure and set
states corresponding to requested voltages.
Yes, so actually the only issue is low/high interpretation.
Maybe the easiest way is a simple array with the voltage,
since t
[U-Boot] [PATCH v2] power: regulator: Add support for gpio regulators
Add support for gpio regulators. As of now this driver caters
to gpio regulators with one gpio. Supports setting voltage values to gpio
regulators and retrieving the values.
Signed-off-by: Keerthy
---
Changes in v2:
* Added states and voltages as part of plat data to have
a generic state to voltage mapping removing any assumptions.
drivers/power/regulator/Kconfig | 8 ++
drivers/power/regulator/Makefile | 1 +
drivers/power/regulator/gpio-regulator.c | 137 +++
include/power/regulator.h| 1 +
4 files changed, 147 insertions(+)
create mode 100644 drivers/power/regulator/gpio-regulator.c
diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 2510474..4776011 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -58,6 +58,14 @@ config DM_REGULATOR_FIXED
features for fixed value regulators. The driver implements get/set api
for enable and get only for voltage value.
+config DM_REGULATOR_GPIO
+ bool "Enable Driver Model for GPIO REGULATOR"
+ depends on DM_REGULATOR
+ ---help---
+ This config enables implementation of driver-model regulator uclass
+ features for gpio regulators. The driver implements get/set for
+ voltage value.
+
config REGULATOR_RK808
bool "Enable driver for RK808 regulators"
depends on DM_REGULATOR && PMIC_RK808
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 2093048..2d350cb 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_RK808) += rk808.o
obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
diff --git a/drivers/power/regulator/gpio-regulator.c
b/drivers/power/regulator/gpio-regulator.c
new file mode 100644
index 000..0a60a9c
--- /dev/null
+++ b/drivers/power/regulator/gpio-regulator.c
@@ -0,0 +1,137 @@
+/*
+ * (C) Copyright 2016 Texas Instruments Incorporated,
+ * Keerthy
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GPIO_REGULATOR_MAX_STATES 2
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct gpio_regulator_platdata {
+ struct gpio_desc gpio; /* GPIO for regulator voltage control */
+ int states[GPIO_REGULATOR_MAX_STATES];
+ int voltages[GPIO_REGULATOR_MAX_STATES];
+};
+
+static int gpio_regulator_ofdata_to_platdata(struct udevice *dev)
+{
+ struct dm_regulator_uclass_platdata *uc_pdata;
+ struct gpio_regulator_platdata *dev_pdata;
+ struct gpio_desc *gpio;
+ const void *blob = gd->fdt_blob;
+ int node = dev->of_offset;
+ int ret, count, i, j;
+ u32 states_array[8];
+
+ dev_pdata = dev_get_platdata(dev);
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (!uc_pdata)
+ return -ENXIO;
+
+ /* Set type to gpio */
+ uc_pdata->type = REGULATOR_TYPE_GPIO;
+
+ /*
+* Get gpio regulator gpio desc
+* Assuming one GPIO per regulator.
+* Can be extended later to multiple GPIOs
+* per gpio-regulator. As of now no instance with multiple
+* gpios is presnt
+*/
+ gpio = &dev_pdata->gpio;
+ ret = gpio_request_by_name(dev, "gpios", 0, gpio, GPIOD_IS_OUT);
+ if (ret)
+ debug("regulator gpio - not found! Error: %d", ret);
+
+ count = fdtdec_get_int_array_count(blob, node, "states",
+ states_array, 8);
+
+ if (!count)
+ return -EINVAL;
+
+ for (i = 0, j = 0; i < count; i += 2) {
+ dev_pdata->voltages[j] = states_array[i];
+ dev_pdata->states[j] = states_array[i + 1];
+ j++;
+ }
+
+ return 0;
+}
+
+static int gpio_regulator_get_value(struct udevice *dev)
+{
+ struct dm_regulator_uclass_platdata *uc_pdata;
+ struct gpio_regulator_platdata *dev_pdata = dev_get_platdata(dev);
+ int enable;
+
+ if (!dev_pdata->gpio.dev)
+ return -ENOSYS;
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (uc_pdata->min_uV > uc_pdata->max_uV) {
+ debug("Invalid constraints for: %s\n", uc_pdata->name);
+ return -EINVAL;
+ }
+
+ enable = dm_gpio_get_value(&dev_pdata->gpio);
+ if (enable == dev_pdata->states[0])
+ return dev_pdata->voltages[0];
+ else
+ return dev_pdata->voltages[1];
+}
+
+static int gpio_regulator_set_value(struct udevice *dev, int uV)
+{
+ struct gpio_r
Re: [U-Boot] [ANN] U-Boot v2016.09 is released
On Wed, Sep 14, 2016 at 11:32:07PM +0200, Daniel Schwierzeck wrote: > Hi Tom, > > Am 12.09.2016 um 18:21 schrieb Tom Rini: > > > > Another thing I'd like to call out, and ask for a little help with too > > is automated testing. The framework in test/py/test.py can be used on > > real hardware and Stephen Warren has been doing a good job having things > > run on Tegra boards. You can see his scripts here[1]. I've setup > > locally some of my boards (some TI, RPi3, A20-OLinuXino-Lime2) and I'm > > looking at adding more still, so long as I can update U-Boot in a way > > that does not involve the console. You can see my scripts here[2] and > > I'm cleaning things up and pushing them back up to Stephen. But there's > > always more to do and test. Is anyone else out there running this on > > real hardware, or would like to set this up? Has anyone out there > > gotten this hooked up with qemu? > > > > I have scripts for running tests on MIPS Malta in Qemu [1]. Currently > the only non-working tests are test_sleep and test_net_tftpboot on Malta > 64Bit. > > I think it's possible to create a generic ConsoleQemu class but I hadn't > time yet to try this. > > [1] https://github.com/danielschwierzeck/u-boot-test-hooks Ah cool. I think between that and what Michal sent me off-list throwing together some helper scripts to fit into Stephens hook scripts should be doable. The only thing I'm not sure about, wrt doing a class is the amount of flags that qemu needs (and how much they vary) compared with sandbox. 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] power: regulator: Add limits checking while setting voltage and current
On Thursday 15 September 2016 04:38 PM, Keerthy wrote:
On Thursday 15 September 2016 04:26 PM, Przemyslaw Marczak wrote:
Hello Keerthy,
On 09/15/2016 10:54 AM, Keerthy wrote:
Currently the specific set ops functions are directly
called without any check for voltage/current limits for a regulator.
Check for them and proceed.
Signed-off-by: Keerthy
---
drivers/power/regulator/regulator-uclass.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 4434e36..089455e 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -41,6 +41,11 @@ int regulator_get_value(struct udevice *dev)
int regulator_set_value(struct udevice *dev, int uV)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+struct dm_regulator_uclass_platdata *uc_pdata;
+
+uc_pdata = dev_get_uclass_platdata(dev);
+if (uV < uc_pdata->min_uV || uV > uc_pdata->max_uV)
+return -EINVAL;
if (!ops || !ops->set_value)
return -ENOSYS;
@@ -61,6 +66,11 @@ int regulator_get_current(struct udevice *dev)
int regulator_set_current(struct udevice *dev, int uA)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+struct dm_regulator_uclass_platdata *uc_pdata;
+
+uc_pdata = dev_get_uclass_platdata(dev);
+if (uA < uc_pdata->min_uA || uA > uc_pdata->max_uA)
+return -EINVAL;
if (!ops || !ops->set_current)
return -ENOSYS;
Adding those two checks will conflict with "force" option for
cmd/regulator.c:283.
There was value range checking in the command's code, but it was left
unchecked
for regulator direct calls.
This change is good, but then maybe the "force" option should be removed
from command,
or API's prototypes should be updated by force flag argument?
I assumed that this option could be useful for quick over-voltage
setting (until reboot),
since usually (min_uV == max_uV) - the voltage can't be changed in any
range.
The driver should take care about ignore it or not, however probably
nobody used this.
Of course this could potentially damage the device by wrong use,
which can be also made by passing the force flag as an argument - by
mistake.
What do you thing about, update the dm_regulator_ops by:
- int (*set_value)(struct udevice *dev, int uV, int flag);
- int (*set_current)(struct udevice *dev, int uA, int flag);
I personally do not like setting an extra flag everywhere just because
we want to support force option.
I would rather have 2 functions like:
int (*force_set_value)(struct udevice *dev, int uV);
int (*force_set_current)(struct udevice *dev, int uA);
Where we can set the value ignoring the limits. But again that must be
used with at most caution as setting higher voltages might end up
damaging the device.
and also new flag to the present defined:
- REGULATOR_FLAG_FORCE = 1 << 2
This requires more work, but will provide the functionality in a proper
way.
I do not know cmd_regulator is the right place to check for min_uV and
max_uV. dm_regulator_uclass_platdata has both the limits and this i feel
is a perfectly valid check in generic place else we would be again
checking for the same condition in every possible regulator specific
drivers.
As far as the force option is concerned that i believe is more for
testing and like you said can be implemented by setting a flag.
Just take a simple case of say a driver like mmc which unknowingly
requests a wrong voltage and the base driver has no check against min
and max voltages and assuming the regulator driver goes ahead and sets a
very high voltage. That can be catastrophic right?
Best regards,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] power: regulator: Add limits checking while setting voltage and current
Hello Keerthy,
On 09/15/2016 10:54 AM, Keerthy wrote:
Currently the specific set ops functions are directly
called without any check for voltage/current limits for a regulator.
Check for them and proceed.
Signed-off-by: Keerthy
---
drivers/power/regulator/regulator-uclass.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 4434e36..089455e 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -41,6 +41,11 @@ int regulator_get_value(struct udevice *dev)
int regulator_set_value(struct udevice *dev, int uV)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+ struct dm_regulator_uclass_platdata *uc_pdata;
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (uV < uc_pdata->min_uV || uV > uc_pdata->max_uV)
+ return -EINVAL;
if (!ops || !ops->set_value)
return -ENOSYS;
@@ -61,6 +66,11 @@ int regulator_get_current(struct udevice *dev)
int regulator_set_current(struct udevice *dev, int uA)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+ struct dm_regulator_uclass_platdata *uc_pdata;
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (uA < uc_pdata->min_uA || uA > uc_pdata->max_uA)
+ return -EINVAL;
if (!ops || !ops->set_current)
return -ENOSYS;
Adding those two checks will conflict with "force" option for
cmd/regulator.c:283.
There was value range checking in the command's code, but it was left
unchecked
for regulator direct calls.
This change is good, but then maybe the "force" option should be removed
from command,
or API's prototypes should be updated by force flag argument?
I assumed that this option could be useful for quick over-voltage
setting (until reboot),
since usually (min_uV == max_uV) - the voltage can't be changed in any
range.
The driver should take care about ignore it or not, however probably
nobody used this.
Of course this could potentially damage the device by wrong use,
which can be also made by passing the force flag as an argument - by
mistake.
What do you thing about, update the dm_regulator_ops by:
- int (*set_value)(struct udevice *dev, int uV, int flag);
- int (*set_current)(struct udevice *dev, int uA, int flag);
and also new flag to the present defined:
- REGULATOR_FLAG_FORCE = 1 << 2
This requires more work, but will provide the functionality in a proper way.
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 0/2] Add TOPIC Miami boards
On 15-09-16 08:54, Michal Simek wrote: Hi Mike, On 15.9.2016 08:02, Mike Looijmans wrote: These patches add support for the Miami range of boards from TOPIC. The boards are based on Xilinx Zynq SoCs, these two patches are for the 7-series, the Ultrascale MPSOC boards are to be added later. Please note that the "ps7_init_gpl" files are largely generated by a tool and as a result of that, contain many style issues. Mike Looijmans (2): Add topic-miami board support Add topic_miamiplus board arch/arm/dts/Makefile |2 + arch/arm/dts/zynq-topic-miami.dts | 98 + arch/arm/dts/zynq-topic-miamiplus.dts | 22 + board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.c | 4324 +++ board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.h | 118 + .../zynq/zynq-topic-miamiplus/ps7_init_gpl.c | 4425 .../zynq/zynq-topic-miamiplus/ps7_init_gpl.h | 150 + configs/topic_miami_defconfig | 47 + configs/topic_miamiplus_defconfig | 47 + include/configs/topic_miami.h | 147 + include/configs/topic_miamiplus.h |2 + 11 files changed, 9382 insertions(+) create mode 100644 arch/arm/dts/zynq-topic-miami.dts create mode 100644 arch/arm/dts/zynq-topic-miamiplus.dts create mode 100644 board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.c create mode 100644 board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.h create mode 100644 board/xilinx/zynq/zynq-topic-miamiplus/ps7_init_gpl.c create mode 100644 board/xilinx/zynq/zynq-topic-miamiplus/ps7_init_gpl.h create mode 100644 configs/topic_miami_defconfig create mode 100644 configs/topic_miamiplus_defconfig create mode 100644 include/configs/topic_miami.h create mode 100644 include/configs/topic_miamiplus.h It is a question if this should go to board/xilinx folder. I think you should create own folder just for your company. Probably doesn't make sense to copy all Makefiles and so but I think you can source them from Xilinx folder to be only at one location. I think a "topic" folder would be better, if I can avoid duplicating stuff. It'd also solve the merge conflict between the u-boot-xlnx tree and mainline, which have different makefiles. The next thing is that there needs to be additional steps to fix ps7_init_gpl.* files to keep checkpatch happy. I have created change request to fix this directly in tools but still none has fixed it and the team which is responsible for it is keep moving to the next release but I can do nothing with it. A bit of scripting would take care of most of the problems I guess. Just removing all those C++ comment lines would be a good start. Currently I just include zynq-common.h and then have to #undef a lot of things. Maybe I'd better just copy the relevant parts and avoid using zynq-common.h. The alternative would be to make zynq-common more common and less specific to the evaluation boards. Mike. Kind regards, Mike Looijmans System Expert TOPIC Products Materiaalweg 4, NL-5681 RJ Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacancy/topic-zoekt-technische-software-engineers/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] power: regulator: Add support for gpio regulators
Hello Keerthy,
On 09/15/2016 10:25 AM, Keerthy wrote:
Add support for gpio regulators. As of now this driver caters
to gpio regulators with one gpio. Supports setting voltage values to gpio
regulators and retrieving the values.
Signed-off-by: Keerthy
---
drivers/power/regulator/Kconfig | 8 ++
drivers/power/regulator/Makefile | 1 +
drivers/power/regulator/gpio-regulator.c | 136 +++
include/power/regulator.h| 1 +
4 files changed, 146 insertions(+)
create mode 100644 drivers/power/regulator/gpio-regulator.c
diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 2510474..4776011 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -58,6 +58,14 @@ config DM_REGULATOR_FIXED
features for fixed value regulators. The driver implements get/set api
for enable and get only for voltage value.
+config DM_REGULATOR_GPIO
+ bool "Enable Driver Model for GPIO REGULATOR"
+ depends on DM_REGULATOR
+ ---help---
+ This config enables implementation of driver-model regulator uclass
+ features for gpio regulators. The driver implements get/set for
+ voltage value.
+
config REGULATOR_RK808
bool "Enable driver for RK808 regulators"
depends on DM_REGULATOR && PMIC_RK808
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 2093048..2d350cb 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_RK808) += rk808.o
obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
diff --git a/drivers/power/regulator/gpio-regulator.c
b/drivers/power/regulator/gpio-regulator.c
new file mode 100644
index 000..9c8832e
--- /dev/null
+++ b/drivers/power/regulator/gpio-regulator.c
@@ -0,0 +1,136 @@
+/*
+ * (C) Copyright 2016 Texas Instruments Incorporated,
+ * Keerthy
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct gpio_regulator_platdata {
+ struct gpio_desc gpio; /* GPIO for regulator voltage control */
+ int gpio_low_uV;
+ int gpio_high_uV;
+};
The low/high values can be provided by regulator's uclass driver in
struct of type "dm_regulator_uclass_platdata", as for other regulators.
But as I can see in the Linux, this driver should provide a structure
for the gpio states.
+
+static int gpio_regulator_ofdata_to_platdata(struct udevice *dev)
+{
+ struct dm_regulator_uclass_platdata *uc_pdata;
+ struct gpio_regulator_platdata *dev_pdata;
+ struct gpio_desc *gpio;
+ const void *blob = gd->fdt_blob;
+ int node = dev->of_offset;
+ int ret, count, i;
+ u32 states_array[8];
+
+ dev_pdata = dev_get_platdata(dev);
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (!uc_pdata)
+ return -ENXIO;
+
+ /* Set type to gpio */
+ uc_pdata->type = REGULATOR_TYPE_GPIO;
+
+ /*
+* Get gpio regulator gpio desc
+* Assuming one GPIO per regulator.
+* Can be extended later to multiple GPIOs
+* per gpio-regulator. As of now no instance with multiple
+* gpios is presnt
+*/
+ gpio = &dev_pdata->gpio;
+ ret = gpio_request_by_name(dev, "gpios", 0, gpio, GPIOD_IS_OUT);
+ if (ret)
+ debug("regulator gpio - not found! Error: %d", ret);
+
+ count = fdtdec_get_int_array_count(blob, node, "states",
+ states_array, 8);
+
+ if (!count)
+ return -EINVAL;
+
+ for (i = 0; i < count; i += 2) {
The below condition is valid for most devices.
In Linux we can find dts for some ARMs in which I can find at least two
boards,
with inverted meaning of state/voltage, so "0", can be also valid for
the high uV.
I think, this driver should keep possible states in platdata.
+ if (states_array[i + 1] == 0)
+ dev_pdata->gpio_low_uV = states_array[i];
+ else
+ dev_pdata->gpio_high_uV = states_array[i];
+ }
+
+ return 0;
+}
+
+static int gpio_regulator_get_value(struct udevice *dev)
+{
+ struct dm_regulator_uclass_platdata *uc_pdata;
+ struct gpio_regulator_platdata *dev_pdata = dev_get_platdata(dev);
+ int enable;
+
+ if (!dev_pdata->gpio.dev)
+ return -ENOSYS;
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (uc_pdata->min_uV > uc_pdata->max_uV) {
+
Re: [U-Boot] [PATCH v3 3/5] regulator: fixed: honour optionality of enable gpio
Hello Marcel,
On 09/15/2016 09:27 AM, Marcel Ziswiler wrote:
According to the binding documentation the fixed regulator enable GPIO
is optional. However so far registration thereof failed if no enable
GPIO was specified. Fix this by making it entirely optional whether an
enable GPIO is used.
Signed-off-by: Marcel Ziswiler
---
Changes in v3:
- Introduce new patch to honour optionality of fixed regulator enable
GPIO.
Changes in v2: None
drivers/power/regulator/fixed.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/power/regulator/fixed.c b/drivers/power/regulator/fixed.c
index 37b8400..c68da70 100644
--- a/drivers/power/regulator/fixed.c
+++ b/drivers/power/regulator/fixed.c
@@ -37,11 +37,12 @@ static int fixed_regulator_ofdata_to_platdata(struct
udevice *dev)
/* Set type to fixed */
uc_pdata->type = REGULATOR_TYPE_FIXED;
- /* Get fixed regulator gpio desc */
+ /* Get fixed regulator optional enable GPIO desc */
gpio = &dev_pdata->gpio;
ret = gpio_request_by_name(dev, "gpio", 0, gpio, GPIOD_IS_OUT);
if (ret)
- debug("Fixed regulator gpio - not found! Error: %d", ret);
+ debug("Fixed reg optional enable GPIO - not found! Error: %d",
+ ret);
The "reg" is usually threated as a "register", so full word is better here.
/* Get optional ramp up delay */
dev_pdata->startup_delay_us = fdtdec_get_uint(gd->fdt_blob,
@@ -87,8 +88,9 @@ static bool fixed_regulator_get_enable(struct udevice *dev)
{
struct fixed_regulator_platdata *dev_pdata = dev_get_platdata(dev);
+ /* Enable GPIO is optional */
if (!dev_pdata->gpio.dev)
- return false;
+ return true;
That is good fix :)
return dm_gpio_get_value(&dev_pdata->gpio);
}
@@ -98,8 +100,9 @@ static int fixed_regulator_set_enable(struct udevice *dev,
bool enable)
struct fixed_regulator_platdata *dev_pdata = dev_get_platdata(dev);
int ret;
+ /* Enable GPIO is optional */
if (!dev_pdata->gpio.dev)
- return -ENOSYS;
+ return 0;
ret = dm_gpio_set_value(&dev_pdata->gpio, enable);
if (ret) {
I don't think, that returning the 0 (success) is a good idea.
We should return some error value, because this is checked
by the regulator's command code.
User can be informed about what was happened - instead of getting
command succeed - but without any results behind the command.
Maybe the -ENOSYS is not the best here. What about -EPERM?
We could assume, that such operation is not permitted for this device.
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 0/2] Add TOPIC Miami boards
On 15-09-16 09:41, Mike Looijmans wrote: On 15-09-16 08:54, Michal Simek wrote: Hi Mike, On 15.9.2016 08:02, Mike Looijmans wrote: These patches add support for the Miami range of boards from TOPIC. The boards are based on Xilinx Zynq SoCs, these two patches are for the 7-series, the Ultrascale MPSOC boards are to be added later. Please note that the "ps7_init_gpl" files are largely generated by a tool and as a result of that, contain many style issues. Mike Looijmans (2): Add topic-miami board support Add topic_miamiplus board arch/arm/dts/Makefile |2 + arch/arm/dts/zynq-topic-miami.dts | 98 + arch/arm/dts/zynq-topic-miamiplus.dts | 22 + board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.c | 4324 +++ board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.h | 118 + .../zynq/zynq-topic-miamiplus/ps7_init_gpl.c | 4425 .../zynq/zynq-topic-miamiplus/ps7_init_gpl.h | 150 + configs/topic_miami_defconfig | 47 + configs/topic_miamiplus_defconfig | 47 + include/configs/topic_miami.h | 147 + include/configs/topic_miamiplus.h |2 + 11 files changed, 9382 insertions(+) create mode 100644 arch/arm/dts/zynq-topic-miami.dts create mode 100644 arch/arm/dts/zynq-topic-miamiplus.dts create mode 100644 board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.c create mode 100644 board/xilinx/zynq/zynq-topic-miami/ps7_init_gpl.h create mode 100644 board/xilinx/zynq/zynq-topic-miamiplus/ps7_init_gpl.c create mode 100644 board/xilinx/zynq/zynq-topic-miamiplus/ps7_init_gpl.h create mode 100644 configs/topic_miami_defconfig create mode 100644 configs/topic_miamiplus_defconfig create mode 100644 include/configs/topic_miami.h create mode 100644 include/configs/topic_miamiplus.h It is a question if this should go to board/xilinx folder. I think you should create own folder just for your company. Probably doesn't make sense to copy all Makefiles and so but I think you can source them from Xilinx folder to be only at one location. I think a "topic" folder would be better, if I can avoid duplicating stuff. It'd also solve the merge conflict between the u-boot-xlnx tree and mainline, which have different makefiles. Oh, wait, no that wouldn't really solve anything. The Makefile conflict is in "arch/arm/dts/Makefile", that's unavoidable. The next thing is that there needs to be additional steps to fix ps7_init_gpl.* files to keep checkpatch happy. I have created change request to fix this directly in tools but still none has fixed it and the team which is responsible for it is keep moving to the next release but I can do nothing with it. A bit of scripting would take care of most of the problems I guess. Just removing all those C++ comment lines would be a good start. Currently I just include zynq-common.h and then have to #undef a lot of things. Maybe I'd better just copy the relevant parts and avoid using zynq-common.h. The alternative would be to make zynq-common more common and less specific to the evaluation boards. Mike. Kind regards, Mike Looijmans System Expert TOPIC Products Materiaalweg 4, NL-5681 RJ Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacancy/topic-zoekt-technische-software-engineers/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request: u-boot-uniphier/master
On Thu, Sep 15, 2016 at 05:40:52PM +0900, Masahiro Yamada wrote: > Hi Tom, > > I found a bug in this series. > If you have not pulled it in yet, > I'd like to cancel it > and do the 2nd round later. OK, thanks! > > Thanks, > > > > > 2016-09-14 23:13 GMT+09:00 Masahiro Yamada : > > Hi Tom, > > > > Here is the fist pull request from me > > for the v2016.11 development cycle. > > > > The following UniPhier updates are included: > > > > - DM migration > > * remove legacy xHCI driver > > * convert MMC driver to CONFIG_BLOCK > > - Pinctrl driver improvements > > * New pin-group > > * Macro cleanup > > - Misc fixes, cleanups > > * Fix DRAM size of LD21 SoC > > * Consolidate board init functions > > > > Please pull! > > > > > > The following changes since commit 8cbb389bb3da80cbf8911f8386cbff92c6a78afe: > > > > Prepare v2016.09 (2016-09-12 10:05:51 -0400) > > > > are available in the git repository at: > > > > git://git.denx.de/u-boot-uniphier.git master > > > > for you to fetch changes up to c55b84c37654e4bf6118d7e37893fdc55f0565e3: > > > > ARM: uniphier: introduce flags to adjust DRAM timing for LD20/LD21 > > (2016-09-14 22:54:20 +0900) > > > > > -- > Best Regards > Masahiro Yamada -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Revert "Increase default of CONFIG_SYS_MALLOC_F_LEN for SPL_OF_CONTROL"
This reverts commit 90c08d9e08c7a108ab904f3bbdeb558081757892. I took a closer look at this and found CONFIG_SYS_MALLOC_F_LEN=0x2000 was too much to enable SPL_OF_CONTROL. Perhaps 0x800 is enough, but the situation varies board by board. Postpone the decision until we come up with a good idea. Signed-off-by: Masahiro Yamada --- Kconfig| 1 - configs/clearfog_defconfig | 1 + configs/db-88f6720_defconfig | 1 + configs/db-88f6820-gp_defconfig| 1 + configs/db-mv784mp-gp_defconfig| 1 + configs/ds414_defconfig| 1 + configs/maxbcm_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + configs/socfpga_arria5_defconfig | 1 + configs/socfpga_cyclone5_defconfig | 1 + configs/socfpga_de0_nano_soc_defconfig | 1 + configs/socfpga_is1_defconfig | 1 + configs/socfpga_mcvevk_defconfig | 1 + configs/socfpga_sockit_defconfig | 1 + configs/socfpga_socrates_defconfig | 1 + configs/socfpga_sr1500_defconfig | 1 + configs/socfpga_vining_fpga_defconfig | 1 + configs/theadorable_debug_defconfig| 1 + configs/theadorable_defconfig | 1 + configs/uniphier_ld11_defconfig| 1 + configs/uniphier_ld20_defconfig| 1 + configs/uniphier_ld4_sld8_defconfig| 1 + configs/uniphier_pro4_defconfig| 1 + configs/uniphier_pxs2_ld6b_defconfig | 1 + configs/uniphier_sld3_defconfig| 1 + 25 files changed, 24 insertions(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index fdea71e..45a0669 100644 --- a/Kconfig +++ b/Kconfig @@ -83,7 +83,6 @@ config SYS_MALLOC_F config SYS_MALLOC_F_LEN hex "Size of malloc() pool before relocation" depends on SYS_MALLOC_F - default 0x2000 if SPL_DM && SPL_OF_CONTROL default 0x400 help Before relocation, memory is very limited on many platforms. Still, diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 778cf06..3bf5388 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_MVEBU=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_CLEARFOG=y CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" CONFIG_SPL=y diff --git a/configs/db-88f6720_defconfig b/configs/db-88f6720_defconfig index b6df961..f06f27f 100644 --- a/configs/db-88f6720_defconfig +++ b/configs/db-88f6720_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_MVEBU=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_DB_88F6720=y CONFIG_DEFAULT_DEVICE_TREE="armada-375-db" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set diff --git a/configs/db-88f6820-gp_defconfig b/configs/db-88f6820-gp_defconfig index 7ac7457..123e7fc 100644 --- a/configs/db-88f6820-gp_defconfig +++ b/configs/db-88f6820-gp_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_MVEBU=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_DB_88F6820_GP=y CONFIG_DEFAULT_DEVICE_TREE="armada-388-gp" CONFIG_SPL=y diff --git a/configs/db-mv784mp-gp_defconfig b/configs/db-mv784mp-gp_defconfig index 510554e..f2c4a9e 100644 --- a/configs/db-mv784mp-gp_defconfig +++ b/configs/db-mv784mp-gp_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_MVEBU=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_DB_MV784MP_GP=y CONFIG_DEFAULT_DEVICE_TREE="armada-xp-gp" # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig index f95a9df..f2b26c7 100644 --- a/configs/ds414_defconfig +++ b/configs/ds414_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_MVEBU=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_DS414=y CONFIG_DEFAULT_DEVICE_TREE="armada-xp-synology-ds414" CONFIG_SPL=y diff --git a/configs/maxbcm_defconfig b/configs/maxbcm_defconfig index 22186c3..b67bc51 100644 --- a/configs/maxbcm_defconfig +++ b/configs/maxbcm_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_MVEBU=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_MAXBCM=y CONFIG_DEFAULT_DEVICE_TREE="armada-xp-maxbcm" CONFIG_SPL=y diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig index 808ac34..0aadaa9 100644 --- a/configs/sandbox_spl_defconfig +++ b/configs/sandbox_spl_defconfig @@ -1,3 +1,4 @@ +CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_MMC=y CONFIG_SANDBOX_SPL=y CONFIG_PCI=y diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig index a6d4945..85e7f85 100644 --- a/configs/socfpga_arria5_defconfig +++ b/configs/socfpga_arria5_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_SOCFPGA_ARRIA5_SOCDK=y CONFIG_SPL_STACK_R_ADDR=0x0080 CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria5_socdk" diff --git a/configs/socfpga_cyclone5_defconfig b/configs/socfpga_cyclone5_defconfig index b34e7e5..27908b9 100644 --- a/configs/socfpga_cyclone5_defconfig +++ b/configs/socfpga_cyclone5_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y +CONFIG_SYS_MALLOC_F_LEN=
Re: [U-Boot] [PATCH] power: regulator: Add limits checking while setting voltage and current
On Thursday 15 September 2016 04:26 PM, Przemyslaw Marczak wrote:
Hello Keerthy,
On 09/15/2016 10:54 AM, Keerthy wrote:
Currently the specific set ops functions are directly
called without any check for voltage/current limits for a regulator.
Check for them and proceed.
Signed-off-by: Keerthy
---
drivers/power/regulator/regulator-uclass.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 4434e36..089455e 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -41,6 +41,11 @@ int regulator_get_value(struct udevice *dev)
int regulator_set_value(struct udevice *dev, int uV)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+struct dm_regulator_uclass_platdata *uc_pdata;
+
+uc_pdata = dev_get_uclass_platdata(dev);
+if (uV < uc_pdata->min_uV || uV > uc_pdata->max_uV)
+return -EINVAL;
if (!ops || !ops->set_value)
return -ENOSYS;
@@ -61,6 +66,11 @@ int regulator_get_current(struct udevice *dev)
int regulator_set_current(struct udevice *dev, int uA)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+struct dm_regulator_uclass_platdata *uc_pdata;
+
+uc_pdata = dev_get_uclass_platdata(dev);
+if (uA < uc_pdata->min_uA || uA > uc_pdata->max_uA)
+return -EINVAL;
if (!ops || !ops->set_current)
return -ENOSYS;
Adding those two checks will conflict with "force" option for
cmd/regulator.c:283.
There was value range checking in the command's code, but it was left
unchecked
for regulator direct calls.
This change is good, but then maybe the "force" option should be removed
from command,
or API's prototypes should be updated by force flag argument?
I assumed that this option could be useful for quick over-voltage
setting (until reboot),
since usually (min_uV == max_uV) - the voltage can't be changed in any
range.
The driver should take care about ignore it or not, however probably
nobody used this.
Of course this could potentially damage the device by wrong use,
which can be also made by passing the force flag as an argument - by
mistake.
What do you thing about, update the dm_regulator_ops by:
- int (*set_value)(struct udevice *dev, int uV, int flag);
- int (*set_current)(struct udevice *dev, int uA, int flag);
and also new flag to the present defined:
- REGULATOR_FLAG_FORCE = 1 << 2
This requires more work, but will provide the functionality in a proper
way.
I do not know cmd_regulator is the right place to check for min_uV and
max_uV. dm_regulator_uclass_platdata has both the limits and this i feel
is a perfectly valid check in generic place else we would be again
checking for the same condition in every possible regulator specific
drivers.
As far as the force option is concerned that i believe is more for
testing and like you said can be implemented by setting a flag.
Just take a simple case of say a driver like mmc which unknowingly
requests a wrong voltage and the base driver has no check against min
and max voltages and assuming the regulator driver goes ahead and sets a
very high voltage. That can be catastrophic right?
Best regards,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 01/12] clk: Use dummy clk_get_by_* functions when CONFIG_CLK is disabled
Hi Paul, 2016-09-12 0:14 GMT+09:00 Paul Burton : > On 11/09/16 14:25, Masahiro Yamada wrote: >> Hi Paul, >> >> 2016-09-09 17:01 GMT+09:00 Paul Burton : >>> On 09/09/16 04:15, Masahiro Yamada wrote: 2016-09-08 15:47 GMT+09:00 Paul Burton : > The implementations of clk_get_by_index & clk_get_by_name are only > available when CONFIG_CLK is enabled. Unless I am missing something, I think this statement also applies to other clk API functions such as clk_request(), clk_free(), clk_get_rate(), etc. >>> >>> Hi Masahiro, >>> >>> Yes, I agree. To be clear though, this patch doesn't add any new stub >>> functions it simply makes the conditions for the existing ones being >>> provided match the conditions for the real implementations not being >>> provided. >>> > Provide the dummies when this is > not the case in order to avoid build failures. Why are other functions OK without dummy stubs? >>> >>> In general, I presume because they aren't used. >>> >>> In the specific case I'm using clk_get_by_index for >>> (drivers/serial/ns16550.c in patch 2 of this series) the fact that the >>> dummy clk_get_by_index always returns an error will cause the compiler >>> to optimise out a call to clk_get_rate so any dummy implementation >>> provided for it wouldn't really get used. >> >> I see, but I do not think it is a good idea >> to rely on the optimization by compiler in this case. >> >> Could you add stubs for other APIs, please? > > Hi Masahiro, > > I don't mind doing that if it's deemed the right approach, but I see it > as very much a separate change to this patch which fixes the condition > for providing the existing stubs so would like if we can consider it > separately. > > As to whether providing stubs for the other functions is correct - I'm > not so sure. Right now, code that makes use of the clock functions but > can also function without CONFIG_CLK will either: > > - Correctly check for errors from the clk_get_* functions and see > calls to the other clock functions get optimised out. This is what > happens in the ns16550 code after my patch 2 of this series, and it is > also the case for other code already in U-Boot (eg. > drivers/usb/host/ehci-generic.c). > > - Get it wrong, not check for errors from clk_get_* properly & get a > fairly easy to track down link error when building U-Boot. > > If we add stub functions for the rest of the clk_* functions then that > second case would become a runtime error rather than a link time one, > and could be missed or overlooked much more easily. If we were to make > the stubs do something like the Linux BUILD_BUG_ON macro then that would > solve that problem, but would require all users of clk_ functions to > #ifdef on CONFIG_CLK. So I actually think the current situation isn't so > bad. OK, thanks for explaining this. (For the case, perhaps drivers that need clk can have "depends on CLK" in Kconfig. Anyway, this should be considered separately.) So, let's go this series as it is. -- 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] power: regulator: Add support for gpio regulators
On Thursday 15 September 2016 03:04 PM, Przemyslaw Marczak wrote:
Hello Keerthy,
On 09/15/2016 10:25 AM, Keerthy wrote:
Add support for gpio regulators. As of now this driver caters
to gpio regulators with one gpio. Supports setting voltage values to gpio
regulators and retrieving the values.
Signed-off-by: Keerthy
---
drivers/power/regulator/Kconfig | 8 ++
drivers/power/regulator/Makefile | 1 +
drivers/power/regulator/gpio-regulator.c | 136
+++
include/power/regulator.h| 1 +
4 files changed, 146 insertions(+)
create mode 100644 drivers/power/regulator/gpio-regulator.c
diff --git a/drivers/power/regulator/Kconfig
b/drivers/power/regulator/Kconfig
index 2510474..4776011 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -58,6 +58,14 @@ config DM_REGULATOR_FIXED
features for fixed value regulators. The driver implements
get/set api
for enable and get only for voltage value.
+config DM_REGULATOR_GPIO
+bool "Enable Driver Model for GPIO REGULATOR"
+depends on DM_REGULATOR
+---help---
+This config enables implementation of driver-model regulator uclass
+features for gpio regulators. The driver implements get/set for
+voltage value.
+
config REGULATOR_RK808
bool "Enable driver for RK808 regulators"
depends on DM_REGULATOR && PMIC_RK808
diff --git a/drivers/power/regulator/Makefile
b/drivers/power/regulator/Makefile
index 2093048..2d350cb 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_RK808) += rk808.o
obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
diff --git a/drivers/power/regulator/gpio-regulator.c
b/drivers/power/regulator/gpio-regulator.c
new file mode 100644
index 000..9c8832e
--- /dev/null
+++ b/drivers/power/regulator/gpio-regulator.c
@@ -0,0 +1,136 @@
+/*
+ * (C) Copyright 2016 Texas Instruments Incorporated,
+ * Keerthy
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct gpio_regulator_platdata {
+struct gpio_desc gpio; /* GPIO for regulator voltage control */
+int gpio_low_uV;
+int gpio_high_uV;
+};
The low/high values can be provided by regulator's uclass driver in
struct of type "dm_regulator_uclass_platdata", as for other regulators.
min_uV, max_uV represent the minimum and maximum voltages in
dm_regulator_uclass_platdata. I would not use them here.
But as I can see in the Linux, this driver should provide a structure
for the gpio states.
Yes so i am keeping the voltage values for 0 and 1 states in a driver
specific struct.
+
+static int gpio_regulator_ofdata_to_platdata(struct udevice *dev)
+{
+struct dm_regulator_uclass_platdata *uc_pdata;
+struct gpio_regulator_platdata *dev_pdata;
+struct gpio_desc *gpio;
+const void *blob = gd->fdt_blob;
+int node = dev->of_offset;
+int ret, count, i;
+u32 states_array[8];
+
+dev_pdata = dev_get_platdata(dev);
+uc_pdata = dev_get_uclass_platdata(dev);
+if (!uc_pdata)
+return -ENXIO;
+
+/* Set type to gpio */
+uc_pdata->type = REGULATOR_TYPE_GPIO;
+
+/*
+ * Get gpio regulator gpio desc
+ * Assuming one GPIO per regulator.
+ * Can be extended later to multiple GPIOs
+ * per gpio-regulator. As of now no instance with multiple
+ * gpios is presnt
+ */
+gpio = &dev_pdata->gpio;
+ret = gpio_request_by_name(dev, "gpios", 0, gpio, GPIOD_IS_OUT);
+if (ret)
+debug("regulator gpio - not found! Error: %d", ret);
+
+count = fdtdec_get_int_array_count(blob, node, "states",
+ states_array, 8);
+
+if (!count)
+return -EINVAL;
+
+for (i = 0; i < count; i += 2) {
The below condition is valid for most devices.
In Linux we can find dts for some ARMs in which I can find at least two
boards,
with inverted meaning of state/voltage, so "0", can be also valid for
the high uV.
I think, this driver should keep possible states in platdata.
Okay. I get the point. So i will have both states and corresponding
states voltages stored in gpio_regulator_platdata structure and set
states corresponding to requested voltages.
+if (states_array[i + 1] == 0)
+dev_pdata->gpio_low_uV = states_array[i];
+else
+dev_pdata->gpio_high_uV = states_array[i];
+}
+
+return 0;
+}
+
+static int gpio_regulator_get_value(struct udevice *dev)
+{
+struct dm_regulator_uclass_platdata *uc_pdata;
+
Re: [U-Boot] [PATCH v3 3/5] regulator: fixed: honour optionality of enable gpio
On Thu, 15 Sep 2016 09:27:22 +0200, Marcel Ziswiler wrote:
> According to the binding documentation the fixed regulator enable GPIO
> is optional. However so far registration thereof failed if no enable
> GPIO was specified. Fix this by making it entirely optional whether an
> enable GPIO is used.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> Changes in v3:
> - Introduce new patch to honour optionality of fixed regulator enable
> GPIO.
>
> Changes in v2: None
>
> drivers/power/regulator/fixed.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/power/regulator/fixed.c b/drivers/power/regulator/fixed.c
> index 37b8400..c68da70 100644
> --- a/drivers/power/regulator/fixed.c
> +++ b/drivers/power/regulator/fixed.c
> @@ -37,11 +37,12 @@ static int fixed_regulator_ofdata_to_platdata(struct
> udevice *dev)
> /* Set type to fixed */
> uc_pdata->type = REGULATOR_TYPE_FIXED;
>
> - /* Get fixed regulator gpio desc */
> + /* Get fixed regulator optional enable GPIO desc */
> gpio = &dev_pdata->gpio;
> ret = gpio_request_by_name(dev, "gpio", 0, gpio, GPIOD_IS_OUT);
> if (ret)
> - debug("Fixed regulator gpio - not found! Error: %d", ret);
> + debug("Fixed reg optional enable GPIO - not found! Error: %d",
> + ret);
If we're changing this, should we tighten up the error handling? It's
only ENOENT that we want to ignore here, other errors should probably
make fixed_regulator_ofdata_to_platdata() fail.
> /* Get optional ramp up delay */
> dev_pdata->startup_delay_us = fdtdec_get_uint(gd->fdt_blob,
> @@ -87,8 +88,9 @@ static bool fixed_regulator_get_enable(struct udevice *dev)
> {
> struct fixed_regulator_platdata *dev_pdata = dev_get_platdata(dev);
>
> + /* Enable GPIO is optional */
> if (!dev_pdata->gpio.dev)
> - return false;
> + return true;
This looks much better to me (I thought I had a similar change locally
but I can't find it now).
> return dm_gpio_get_value(&dev_pdata->gpio);
> }
> @@ -98,8 +100,9 @@ static int fixed_regulator_set_enable(struct udevice *dev,
> bool enable)
> struct fixed_regulator_platdata *dev_pdata = dev_get_platdata(dev);
> int ret;
>
> + /* Enable GPIO is optional */
> if (!dev_pdata->gpio.dev)
> - return -ENOSYS;
> + return 0;
I'm not sure about this change, the current behaviour seems correct to
me. After this we're pretending that fixed_set_enable(dev, false) has
succeeded, when it has not.
> ret = dm_gpio_set_value(&dev_pdata->gpio, enable);
> if (ret) {
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fixup! ARM: uniphier: fix DRAM size of LD21 SoC package
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-uniphier/boards.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-uniphier/boards.c b/arch/arm/mach-uniphier/boards.c
index 1dececb..79b1d20 100644
--- a/arch/arm/mach-uniphier/boards.c
+++ b/arch/arm/mach-uniphier/boards.c
@@ -236,7 +236,7 @@ static const struct uniphier_board_data uniphier_ld21_data
= {
},
.dram_ch[1] = {
.base = 0xc000,
- .size = 0x2000,
+ .size = 0x4000,
.width = 32,
},
.flags = UNIPHIER_BD_BOARD_LD21_GLOBAL,
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] power: regulator: Add limits checking while setting voltage and current
Currently the specific set ops functions are directly
called without any check for voltage/current limits for a regulator.
Check for them and proceed.
Signed-off-by: Keerthy
---
drivers/power/regulator/regulator-uclass.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 4434e36..089455e 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -41,6 +41,11 @@ int regulator_get_value(struct udevice *dev)
int regulator_set_value(struct udevice *dev, int uV)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+ struct dm_regulator_uclass_platdata *uc_pdata;
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (uV < uc_pdata->min_uV || uV > uc_pdata->max_uV)
+ return -EINVAL;
if (!ops || !ops->set_value)
return -ENOSYS;
@@ -61,6 +66,11 @@ int regulator_get_current(struct udevice *dev)
int regulator_set_current(struct udevice *dev, int uA)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+ struct dm_regulator_uclass_platdata *uc_pdata;
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (uA < uc_pdata->min_uA || uA > uc_pdata->max_uA)
+ return -EINVAL;
if (!ops || !ops->set_current)
return -ENOSYS;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request: u-boot-uniphier/master
Hi Tom, I found a bug in this series. If you have not pulled it in yet, I'd like to cancel it and do the 2nd round later. Thanks, 2016-09-14 23:13 GMT+09:00 Masahiro Yamada : > Hi Tom, > > Here is the fist pull request from me > for the v2016.11 development cycle. > > The following UniPhier updates are included: > > - DM migration > * remove legacy xHCI driver > * convert MMC driver to CONFIG_BLOCK > - Pinctrl driver improvements > * New pin-group > * Macro cleanup > - Misc fixes, cleanups > * Fix DRAM size of LD21 SoC > * Consolidate board init functions > > Please pull! > > > The following changes since commit 8cbb389bb3da80cbf8911f8386cbff92c6a78afe: > > Prepare v2016.09 (2016-09-12 10:05:51 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-uniphier.git master > > for you to fetch changes up to c55b84c37654e4bf6118d7e37893fdc55f0565e3: > > ARM: uniphier: introduce flags to adjust DRAM timing for LD20/LD21 > (2016-09-14 22:54:20 +0900) > -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] power: regulator: Add support for gpio regulators
Add support for gpio regulators. As of now this driver caters
to gpio regulators with one gpio. Supports setting voltage values to gpio
regulators and retrieving the values.
Signed-off-by: Keerthy
---
drivers/power/regulator/Kconfig | 8 ++
drivers/power/regulator/Makefile | 1 +
drivers/power/regulator/gpio-regulator.c | 136 +++
include/power/regulator.h| 1 +
4 files changed, 146 insertions(+)
create mode 100644 drivers/power/regulator/gpio-regulator.c
diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index 2510474..4776011 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -58,6 +58,14 @@ config DM_REGULATOR_FIXED
features for fixed value regulators. The driver implements get/set api
for enable and get only for voltage value.
+config DM_REGULATOR_GPIO
+ bool "Enable Driver Model for GPIO REGULATOR"
+ depends on DM_REGULATOR
+ ---help---
+ This config enables implementation of driver-model regulator uclass
+ features for gpio regulators. The driver implements get/set for
+ voltage value.
+
config REGULATOR_RK808
bool "Enable driver for RK808 regulators"
depends on DM_REGULATOR && PMIC_RK808
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 2093048..2d350cb 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o
obj-$(CONFIG_REGULATOR_RK808) += rk808.o
obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
diff --git a/drivers/power/regulator/gpio-regulator.c
b/drivers/power/regulator/gpio-regulator.c
new file mode 100644
index 000..9c8832e
--- /dev/null
+++ b/drivers/power/regulator/gpio-regulator.c
@@ -0,0 +1,136 @@
+/*
+ * (C) Copyright 2016 Texas Instruments Incorporated,
+ * Keerthy
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct gpio_regulator_platdata {
+ struct gpio_desc gpio; /* GPIO for regulator voltage control */
+ int gpio_low_uV;
+ int gpio_high_uV;
+};
+
+static int gpio_regulator_ofdata_to_platdata(struct udevice *dev)
+{
+ struct dm_regulator_uclass_platdata *uc_pdata;
+ struct gpio_regulator_platdata *dev_pdata;
+ struct gpio_desc *gpio;
+ const void *blob = gd->fdt_blob;
+ int node = dev->of_offset;
+ int ret, count, i;
+ u32 states_array[8];
+
+ dev_pdata = dev_get_platdata(dev);
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (!uc_pdata)
+ return -ENXIO;
+
+ /* Set type to gpio */
+ uc_pdata->type = REGULATOR_TYPE_GPIO;
+
+ /*
+* Get gpio regulator gpio desc
+* Assuming one GPIO per regulator.
+* Can be extended later to multiple GPIOs
+* per gpio-regulator. As of now no instance with multiple
+* gpios is presnt
+*/
+ gpio = &dev_pdata->gpio;
+ ret = gpio_request_by_name(dev, "gpios", 0, gpio, GPIOD_IS_OUT);
+ if (ret)
+ debug("regulator gpio - not found! Error: %d", ret);
+
+ count = fdtdec_get_int_array_count(blob, node, "states",
+ states_array, 8);
+
+ if (!count)
+ return -EINVAL;
+
+ for (i = 0; i < count; i += 2) {
+ if (states_array[i + 1] == 0)
+ dev_pdata->gpio_low_uV = states_array[i];
+ else
+ dev_pdata->gpio_high_uV = states_array[i];
+ }
+
+ return 0;
+}
+
+static int gpio_regulator_get_value(struct udevice *dev)
+{
+ struct dm_regulator_uclass_platdata *uc_pdata;
+ struct gpio_regulator_platdata *dev_pdata = dev_get_platdata(dev);
+ int enable;
+
+ if (!dev_pdata->gpio.dev)
+ return -ENOSYS;
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (uc_pdata->min_uV > uc_pdata->max_uV) {
+ debug("Invalid constraints for: %s\n", uc_pdata->name);
+ return -EINVAL;
+ }
+
+ enable = dm_gpio_get_value(&dev_pdata->gpio);
+ if (enable)
+ return dev_pdata->gpio_high_uV;
+ else
+ return dev_pdata->gpio_low_uV;
+}
+
+static int gpio_regulator_set_value(struct udevice *dev, int uV)
+{
+ struct gpio_regulator_platdata *dev_pdata = dev_get_platdata(dev);
+ int ret;
+ bool enable;
+
+ if (!dev_pdata->gpio.dev)
+ return -ENOSYS;
+
+ if (uV == dev_pdata->gpio_high_uV
Re: [U-Boot] [PATCH 1/5] power: regulator: Add ctrl_reg and volt_reg fields for pmic
On Wednesday 14 September 2016 05:26 PM, Przemyslaw Marczak wrote:
Hello Keerthy,
On 09/14/2016 10:24 AM, Keerthy wrote:
Hi Marczak,
On Wednesday 14 September 2016 01:33 PM, Przemyslaw Marczak wrote:
Hello Keerthy,
On 09/14/2016 06:28 AM, Keerthy wrote:
The ctrl reg contains bit fields to enable and disable regulators,
and volt_reg has the bit fields to configure the voltage values.
The registers are frequently accessed hence make them part
of dm_regulator_uclass_platdata structure.
Signed-off-by: Keerthy
---
include/power/regulator.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/power/regulator.h b/include/power/regulator.h
index 9bcd728..57b14a3 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -171,6 +171,8 @@ struct dm_regulator_uclass_platdata {
bool boot_on;
const char *name;
int flags;
+u8 ctrl_reg;
+u8 volt_reg;
};
/* Regulator device operations */
This structure above is used for some common "high-level" data, which
can be used by regulator uclass driver.
Even if most of PMICs has some ctrl/volt/etc regs, the regulator uclass
driver doesn't know, how to use it, so from this point of view it is
useless.
But, you can keep device/driver data in a proper fields. Please look at
those files:
drivers/power/regulator/fixed.c:119
drivers/power/regulator/pfuze100.c:567
To store some device internal data, you can use:
.platdata_auto_alloc_size -> with access by dev_get_platdata()
.priv_auto_alloc_size -> with access by dev_get_priv()
Thanks for a quick review. I did look at some of those options before
introducing volt and ctrl here.
Many PMICs will have ctrl/volt registers we might end up having lot of
private strutures with the same ctrl/volt fields. I agree uclass
driver will not know how to use it.
If i have to draw parallels from the kernel world regulator_desc is a
common structure which hosts vsel_reg/enable_reg fields.
Isn't it better to have a common structure instead of having a some
platform specific structure that might have the same fields?
Let me know your thoughts on this.
Best regards,
You are right and I agree with you that make things common is a good
approach.
At the begin of introducing this framework, I just wanted to provide a
simple user interface for regulators, so I didn't tried to put all
common things into a single structure, because not always it could be
useful.
The present structure layout seems to be a good representation of
regulator's node in the device-tree.
In the other hand, each driver can provide a static arrays with proper
data like reg/mask/etc,
the driver:
drivers/power/regulator/s5m8767.c- is a good example.
I'm not going to break your solution, but let's wait for Simon's opinion.
okay.
Best regards,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] interaction between CONFIG_CMD_SAVEENV and CONFIG_BOOTCOMMAND
Dear Wolfgang, Regarding your recommendations about U-Boot usage, I completely agree with that. In fact, In my description, I wouldn't give too many details, but your answer leads me to add some :-) As I told you, this "old" u-boot is used only as primary bootloader, and its main objective is just to "source" a script on an external device. Note that this script is only a text file that can be modified by the user. We propose different script examples to the user, the basic one will only start the kernel (all images will be stored on the external device), but the most used one will start a secondary bootloader, so a second u-boot (this one is currently in rebasing phase, on 2016.09 release). And in this second u-boot, there is no access restrictions, user will be able to custom. Finally note that this is an intermediate step of our project. In final release, this "primary u-boot" will be replaced by a "bootrom" (so no more u-boot), and in that case, we will have only one "secondary" u-boot. Hope this clarifies :-) Back to our issue on our "primary" u-boot, we found an alternative. We generate two binaries, the first one used only to flash the second. In that case, we are able te disallow use of external env for the second and flash access (define CONFIG_ENV_IS_NOWHERE and undef CONFIG_XXX_FLASH). It seems functional after further tests. So indeed, there is a bug, but on our side, not in u-boot. We need "saveenv" to flash, our script was using the .elf (via gdb) to flash the .bin. And this flash operation was using the saveenv. So by using two differents binaries, we solve our issue, and u-boot is going well :-) Thanks Wolfgang for tyour reactivity and your recommendations. Please note that in our final product, we'll use u-boot with total respect of its philosophy, and we'll be aligned on one of the latest releases :) Best regards, Nicolas 2016-09-14 20:38 GMT+02:00 Wolfgang Denk : > Dear Nicolas, > > In message oyeldam5vr+...@mail.gmail.com> you wrote: > > > > > Would that really be enough? Please keep in mind that "env save" (or > > > "saveenv") is only responsible for storing the current environment > > > into persistant storage. It does not modify the environment at all. > > > To modify the environment, you can use quite a number of commands, > > > including "env set", "env import" etc. You would have to disable all > > > of these to prevent modifications of the environment settings - and > > > probably cripple U-Boot to a level where it becomes unusable. > > > > >> Our objective is just to avoid the user to modify the content in the > > persistent storage. Indeed, we have to retrieve the original content at > > each reboot. > > If the user makes something wrong in its current environment, this is its > > responsability, but after the reset, we have to gat back the original > > content we stored once for all. In that case, saveenv would maybe be > > enough, don't you think? > > It should work as you expect. > > But since you ask what I _think_ ... :-) As a developer I really hate > systems that attempt to lock me down into such a crippled environment. > I still love and cherish the old quote: > > "UNIX was not designed to stop you from doing stupid things, because > that would also stop you from doing clever things." - Doug Gwyn > > You plan to implement a policy that restricts the freedom of the user > for a questionable (to me - I don't know your requirements) advantage. > Would it not be possible to implement a more open design, where the > user can actually save his changes to the persistent environment > (so someone who knows what he is doing can use the full power of the > software), and instead provide a way to perform a factory reset (using > "env default -f" or similar) to your original settings? That would > feel much more U-Boot-like to me :-) > > > > > Which exact version of U-Boot are you talking about? > > >> a quite old one, v2015.01 :-( And we do not plan to upgrade this > > "primary bootloader" u-boot. > > Hm... this should still not show such behaviour. Check your board > config file thoroughly, especially your environment settings. Check > that environment definitions are explicitly terminated by NUL > characters, and that all string quotes pair. If you have any #ifdef > magic there, check that, too. > > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > All I ask is a chance to prove that money can't make me happy. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/5] regulator: fixed: honour optionality of enable gpio
According to the binding documentation the fixed regulator enable GPIO
is optional. However so far registration thereof failed if no enable
GPIO was specified. Fix this by making it entirely optional whether an
enable GPIO is used.
Signed-off-by: Marcel Ziswiler
---
Changes in v3:
- Introduce new patch to honour optionality of fixed regulator enable
GPIO.
Changes in v2: None
drivers/power/regulator/fixed.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/power/regulator/fixed.c b/drivers/power/regulator/fixed.c
index 37b8400..c68da70 100644
--- a/drivers/power/regulator/fixed.c
+++ b/drivers/power/regulator/fixed.c
@@ -37,11 +37,12 @@ static int fixed_regulator_ofdata_to_platdata(struct
udevice *dev)
/* Set type to fixed */
uc_pdata->type = REGULATOR_TYPE_FIXED;
- /* Get fixed regulator gpio desc */
+ /* Get fixed regulator optional enable GPIO desc */
gpio = &dev_pdata->gpio;
ret = gpio_request_by_name(dev, "gpio", 0, gpio, GPIOD_IS_OUT);
if (ret)
- debug("Fixed regulator gpio - not found! Error: %d", ret);
+ debug("Fixed reg optional enable GPIO - not found! Error: %d",
+ ret);
/* Get optional ramp up delay */
dev_pdata->startup_delay_us = fdtdec_get_uint(gd->fdt_blob,
@@ -87,8 +88,9 @@ static bool fixed_regulator_get_enable(struct udevice *dev)
{
struct fixed_regulator_platdata *dev_pdata = dev_get_platdata(dev);
+ /* Enable GPIO is optional */
if (!dev_pdata->gpio.dev)
- return false;
+ return true;
return dm_gpio_get_value(&dev_pdata->gpio);
}
@@ -98,8 +100,9 @@ static int fixed_regulator_set_enable(struct udevice *dev,
bool enable)
struct fixed_regulator_platdata *dev_pdata = dev_get_platdata(dev);
int ret;
+ /* Enable GPIO is optional */
if (!dev_pdata->gpio.dev)
- return -ENOSYS;
+ return 0;
ret = dm_gpio_set_value(&dev_pdata->gpio, enable);
if (ret) {
--
2.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 5/5] colibri_t20: fix usb operation and controller order
Without this patch the following error will be shown:
Colibri T20 # usb start
starting USB...
No controllers found
This patch fixes USB operation and also the controller order as the
CI UDC driver may only be instantiated on the first aka OTG port.
Signed-off-by: Marcel Ziswiler
Acked-by: Stephen Warren
---
Changes in v3:
- Add Stephen's ack.
Changes in v2:
- No change.
- As suggested by Stephen remove last patch 5/5 colibri_t20: enable dfu
also for nand.
arch/arm/dts/tegra20-colibri.dts | 45 +---
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/arch/arm/dts/tegra20-colibri.dts b/arch/arm/dts/tegra20-colibri.dts
index 5b803d9..6bc8c49 100644
--- a/arch/arm/dts/tegra20-colibri.dts
+++ b/arch/arm/dts/tegra20-colibri.dts
@@ -14,10 +14,10 @@
i2c0 = "/i2c@7000d000";
i2c1 = "/i2c@7000c000";
i2c2 = "/i2c@7000c400";
- usb0 = "/usb@c5008000";
- usb1 = "/usb@c500";
- usb2 = "/usb@c5004000";
sdhci0 = "/sdhci@c8000600";
+ usb0 = "/usb@c500";
+ usb1 = "/usb@c5004000"; /* on-module only, for ASIX */
+ usb2 = "/usb@c5008000";
};
host1x@5000 {
@@ -43,24 +43,6 @@
};
};
- usb@c500 {
- statuc = "okay";
- dr_mode = "otg";
- };
-
- usb@c5004000 {
- statuc = "okay";
- /* VBUS_LAN */
- nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1)
GPIO_ACTIVE_HIGH>;
- nvidia,vbus-gpio = <&gpio TEGRA_GPIO(BB, 1) GPIO_ACTIVE_HIGH>;
- };
-
- usb@c5008000 {
- statuc = "okay";
- /* USBH_PEN */
- nvidia,vbus-gpio = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_LOW>;
- };
-
nand-controller@70008000 {
nvidia,wp-gpios = <&gpio TEGRA_GPIO(S, 0) GPIO_ACTIVE_HIGH>;
nvidia,width = <8>;
@@ -101,6 +83,27 @@
clock-frequency = <10>;
};
+ /* EHCI instance 0: USB1_DP/N -> USBC_P/N */
+ usb@c500 {
+ status = "okay";
+ dr_mode = "otg";
+ };
+
+ /* EHCI instance 1: ULPI -> USB3340 -> AX88772B */
+ usb@c5004000 {
+ status = "okay";
+ /* VBUS_LAN */
+ nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1)
GPIO_ACTIVE_HIGH>;
+ nvidia,vbus-gpio = <&gpio TEGRA_GPIO(BB, 1) GPIO_ACTIVE_HIGH>;
+ };
+
+ /* EHCI instance 2: USB3_DP/N -> USBH_P/N */
+ usb@c5008000 {
+ status = "okay";
+ /* USBH_PEN */
+ nvidia,vbus-gpio = <&gpio TEGRA_GPIO(W, 2) GPIO_ACTIVE_LOW>;
+ };
+
sdhci@c8000600 {
status = "okay";
bus-width = <4>;
--
2.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/5] various fixes mainly for colibri_t20
This series addresses various issues as seen on Colibri T20. Please note that for successful Ethernet operation not only on Colibri T20 but also on Colibri T30 the following patch will still be required already waiting in Marek's usb tree: [PATCH v2] net: asix: Fix ASIX 88772B with driver model https://www.mail-archive.com/u-boot@lists.denx.de/msg224349.html Changes in v3: - Add Stephen's ack. - No change. - Introduce new patch to honour optionality of fixed regulator enable GPIO. - Get rid of dummy N/C GPIO work around now as the fixed regulator properly honours optionality of enable GPIO. - Add Stephen's ack. Changes in v2: - As suggested by Stephen gating the CONFIG_CI_UDC_HAS_HOSTPC define with CONFIG_TEGRA20 rather than duplicating the same into all other SoC type specific header files. - Add Anatolij's ack. - Rename dummy regulator to reg_3v3 as suggested by Stephen. - Keep dummy N/C GPIO to work around bug in U-Boot regulator driver requiring such node despite its binding claiming it being optional. - No change. - As suggested by Stephen remove last patch 5/5 colibri_t20: enable dfu also for nand. Marcel Ziswiler (5): tegra: usb gadget: fix ci udc operation if not hostpc capable simple panel: fix spelling of debug message regulator: fixed: honour optionality of enable gpio colibri_t20: fix display configuration colibri_t20: fix usb operation and controller order arch/arm/dts/tegra20-colibri.dts | 116 +++--- drivers/power/regulator/fixed.c | 11 +-- drivers/video/simple_panel.c | 2 +- include/configs/tegra-common-usb-gadget.h | 2 + 4 files changed, 85 insertions(+), 46 deletions(-) -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/5] tegra: usb gadget: fix ci udc operation if not hostpc capable
The Tegra 2 aka T20 is not host PC capable. Therefore gate the define CONFIG_CI_UDC_HAS_HOSTPC in tegra-common-usb-gadget.h in case of CONFIG_TEGRA20. Signed-off-by: Marcel Ziswiler Acked-by: Stephen Warren --- Changes in v3: - Add Stephen's ack. Changes in v2: - As suggested by Stephen gating the CONFIG_CI_UDC_HAS_HOSTPC define with CONFIG_TEGRA20 rather than duplicating the same into all other SoC type specific header files. include/configs/tegra-common-usb-gadget.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/tegra-common-usb-gadget.h b/include/configs/tegra-common-usb-gadget.h index 3e3eeea..2e492c1 100644 --- a/include/configs/tegra-common-usb-gadget.h +++ b/include/configs/tegra-common-usb-gadget.h @@ -10,7 +10,9 @@ #ifndef CONFIG_SPL_BUILD /* USB gadget mode support*/ +#ifndef CONFIG_TEGRA20 #define CONFIG_CI_UDC_HAS_HOSTPC +#endif /* USB mass storage protocol */ #define CONFIG_USB_FUNCTION_MASS_STORAGE /* DFU protocol */ -- 2.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/5] colibri_t20: fix display configuration
Without this patch the following error will be shown:
stdio_add_devices: Video device failed (ret=-22)
As commit ec5507707a1d1e84056a6c864338f95f6118d3ca (video: tegra: Move
to using simple-panel and pwm-backlight) states the Colibri T20 needs
updating too which this patch finally attempts doing.
Signed-off-by: Marcel Ziswiler
---
Changes in v3:
- Get rid of dummy N/C GPIO work around now as the fixed regulator
properly honours optionality of enable GPIO.
Changes in v2:
- Rename dummy regulator to reg_3v3 as suggested by Stephen.
- Keep dummy N/C GPIO to work around bug in U-Boot regulator driver
requiring such node despite its binding claiming it being optional.
arch/arm/dts/tegra20-colibri.dts | 71 +---
1 file changed, 51 insertions(+), 20 deletions(-)
diff --git a/arch/arm/dts/tegra20-colibri.dts b/arch/arm/dts/tegra20-colibri.dts
index 2cf24d3..5b803d9 100644
--- a/arch/arm/dts/tegra20-colibri.dts
+++ b/arch/arm/dts/tegra20-colibri.dts
@@ -21,12 +21,24 @@
};
host1x@5000 {
- status = "okay";
dc@5420 {
- status = "okay";
rgb {
status = "okay";
nvidia,panel = <&lcd_panel>;
+ display-timings {
+ timing@0 {
+ /* VESA VGA */
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ hsync-len = <96>;
+ vback-porch = <31>;
+ vfront-porch = <11>;
+ vsync-len = <2>;
+ };
+ };
};
};
};
@@ -60,6 +72,10 @@
};
};
+ pwm@7000a000 {
+ status = "okay";
+ };
+
/*
* GEN1_I2C: I2C_SDA/SCL on SODIMM pin 194/196 (e.g. RTC on carrier
* board)
@@ -91,6 +107,18 @@
cd-gpios = <&gpio TEGRA_GPIO(C, 7) GPIO_ACTIVE_LOW>;
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+
+ brightness-levels = <255 128 64 32 16 8 4 0>;
+ default-brightness-level = <6>;
+ /* BL_ON */
+ enable-gpios = <&gpio TEGRA_GPIO(T, 4) GPIO_ACTIVE_HIGH>;
+ power-supply = <®_3v3>;
+ /* PWM */
+ pwms = <&pwm 0 500>;
+ };
+
clocks {
compatible = "simple-bus";
#address-cells = <1>;
@@ -104,25 +132,28 @@
};
};
- pwm: pwm@7000a000 {
- status = "okay";
+ lcd_panel: panel {
+ /*
+* edt,et057090dhu: EDT 5.7" LCD TFT
+* edt,et070080dh6: EDT 7.0" LCD TFT
+*/
+ compatible = "edt,et057090dhu", "simple-panel";
+
+ backlight = <&backlight>;
};
- lcd_panel: panel {
- clock = <25175000>;
- xres = <640>;
- yres = <480>;
- left-margin = <48>; /* horizontal back porch */
- right-margin = <16>;/* horizontal front porch */
- hsync-len = <96>;
- lower-margin = <11>;/* vertical front porch */
- upper-margin = <31>;/* vertical back porch */
- vsync-len = <2>;
- hsync-active-high;
- vsync-active-high;
- nvidia,bits-per-pixel = <16>;
- nvidia,pwm = <&pwm 0 0>;
- nvidia,backlight-enable-gpios = <&gpio TEGRA_GPIO(T, 4)
GPIO_ACTIVE_HIGH>;
- nvidia,panel-timings = <0 0 0 0>;
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_3v3: regulator@0 {
+ compatible = "regulator-fixed";
+ reg = <0>;
+ regulator-name = "+V3.3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
};
};
--
2.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/5] simple panel: fix spelling of debug message
Fix spelling of debug message from cnnot to cannot.
Signed-off-by: Marcel Ziswiler
Acked-by: Anatolij Gustschin
---
Changes in v3:
- No change.
Changes in v2:
- Add Anatolij's ack.
drivers/video/simple_panel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/simple_panel.c b/drivers/video/simple_panel.c
index b2fe345..baa95f6 100644
--- a/drivers/video/simple_panel.c
+++ b/drivers/video/simple_panel.c
@@ -42,7 +42,7 @@ static int simple_panel_ofdata_to_platdata(struct udevice
*dev)
ret = uclass_get_device_by_phandle(UCLASS_REGULATOR, dev,
"power-supply", &priv->reg);
if (ret) {
- debug("%s: Warning: cnnot get power supply: ret=%d\n",
+ debug("%s: Warning: cannot get power supply: ret=%d\n",
__func__, ret);
if (ret != -ENOENT)
return ret;
--
2.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
