Re: [U-Boot] [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC
On December 7, 2016 4:47:23 AM CET, Simon Glass wrote:
>Hi Oliver,
>
>On 5 December 2016 at 03:28, Olliver Schinagl
>wrote:
>> Hey Simon,
>>
>>
>>
>> On 05-12-16 07:24, Simon Glass wrote:
>>>
>>> Hi Oliver,
>>>
>>> On 2 December 2016 at 03:16, Olliver Schinagl
>wrote:
Hey Joe,
On 30-11-16 21:40, Joe Hershberger wrote:
>
> On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl
>
> wrote:
>>
>> This patch adds a method for the board to set the MAC address if
>the
>> environment is not yet set. The environment based MAC addresses
>are not
>> touched, but if the fdt has an alias set, it is parsed and put
>into the
>> environment.
>>
>> E.g. The environment contains ethaddr and eth1addr, and the fdt
>> contains
>> an ethernet1 nothing happens. If the fdt contains ethernet2
>however, it
>> is parsed and inserted into the environment as eth2addr.
>>
>> Signed-off-by: Olliver Schinagl
>> ---
>>common/fdt_support.c | 8 +++-
>>1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/common/fdt_support.c b/common/fdt_support.c
>> index c34a13c..f127392 100644
>> --- a/common/fdt_support.c
>> +++ b/common/fdt_support.c
>> @@ -465,6 +465,11 @@ int fdt_fixup_memory(void *blob, u64 start,
>u64
>> size)
>> return fdt_fixup_memory_banks(blob, &start, &size, 1);
>>}
>>
>> +__weak int board_get_enetaddr(const int i, unsigned char
>*mac_addr)
>
> Ugh. This collides with a function in board/v38b/ethaddr.c and in
> board/intercontrol/digsy_mtc/digsy_mtc.c
>
> Also, it's so generic, and only gets called by the fdt fixup
>stuff...
> This function should probably be named in such a way that its
> association with fdt is clear.
I did not notice that, sorry! But naming suggestions are welcome :)
Right now, I use it in two unrelated spots however.
from the fdt as seen above and in a subclass driver (which will
>come up
for
review) as suggested by Simon.
There I do:
+static int sunxi_gmac_eth_read_rom_hwaddr(struct udevice *dev)
+{
+ struct eth_pdata *pdata = dev_get_platdata(dev);
+
+ return board_get_enetaddr(dev->seq, pdata->enetaddr);
+}
+
const struct eth_ops sunxi_gmac_eth_ops = {
.start = designware_eth_start,
.send = designware_eth_send,
@@ -102,6 +110,7 @@ const struct eth_ops sunxi_gmac_eth_ops = {
.free_pkt = designware_eth_free_pkt,
.stop = designware_eth_stop,
.write_hwaddr = designware_eth_write_hwaddr,
+ .read_rom_hwaddr= sunxi_gmac_eth_read_rom_hwaddr,
};
which is completly unrelated to the fdt.
So naming suggestion or overal suggestion how to handle this nice
>and
generically?
Based from the name however I would think that all
>board_get_enetaddr's
work
the same however so should have been interchangeable? Or was that
>silly
thinking?
>>>
>>> Would it be possible to use a name without 'board' in it? I think
>this
>>> / hope is actually sunxi-specific code, not board-specific?
>>
>> You are actually correct, we take the serial number of the SoC (sunxi
>> specific) and generate a serial/MAC from it. So nothing to do with
>the
>> board. So I can just name it sunxi_gen_enetaddr(). Would that be then
>(much)
>> better?
>>
>> The reason why I went to 'board' with my mind, is because a) the
>original
>> mac gen code and b) the location was in board/sunxi/board.c. I think
>it is
>> thus also sensible to move it out of board/sunxi/board.c as indeed,
>it has
>> nothing to do with board(s).
>
>That sounds good to me - and you should be able to call it directly
>from the driver and avoid any weak functions, right?
The subclass driver can, the fdt fixup however still needs a weak
fdt_get_enetaddr()? (Which in our case calls then sunxi_get_enetaddr() i think.)
>
>Regards,
>Simon
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/17] arm: mvebu: Implement secure boot
Hi Stefan, On Thu, Dec 1, 2016 at 10:15 AM, Stefan Roese wrote: > On 23.11.2016 16:12, Mario Six wrote: >> The patch implements secure booting for the mvebu architecture. >> >> This includes: >> - The addition of secure headers and all needed signatures and keys in >> mkimage >> - Commands capable of writing the board's efuses to both write the >> needed cryptographic data and enable the secure booting mechanism >> - The creation of convenience text files containing the necessary >> commands to write the efuses >> >> The KAK and CSK keys are expected to reside in the files kwb_kak.key and >> kwb_csk.key (OpenSSL 2048 bit private keys) in the top-level directory. >> >> Signed-off-by: Reinhard Pfau >> Signed-off-by: Mario Six > > Thanks Mario, I have to admit that I'm pretty new to this secure booting > support on A38x. So I can't really comment much on the technical details. > I would very much like to see some documentation being added for this > secure boot support on A38x (doc/...). With a more detailed explanation > of this procedure and best one exmaple on how this is done in practice. > I'll add some documentation in v2. > Please find some more comments below. > >> --- >> Makefile | 3 +- >> arch/arm/mach-mvebu/Kconfig | 20 + >> arch/arm/mach-mvebu/Makefile | 1 + >> arch/arm/mach-mvebu/efuse.c | 293 >> arch/arm/mach-mvebu/include/mach/cpu.h | 2 + >> arch/arm/mach-mvebu/include/mach/efuse.h | 71 +++ >> tools/Makefile | 6 +- >> tools/kwbimage.c | 744 >> ++- >> tools/kwbimage.h | 37 ++ >> 9 files changed, 1169 insertions(+), 8 deletions(-) >> create mode 100644 arch/arm/mach-mvebu/efuse.c >> create mode 100644 arch/arm/mach-mvebu/include/mach/efuse.h >> >> diff --git a/Makefile b/Makefile >> index 96ddc59..05a38af 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -938,7 +938,8 @@ MKIMAGEFLAGS_u-boot.kwb = -n >> $(srctree)/$(CONFIG_SYS_KWD_CONFIG:"%"=%) \ >> -T kwbimage -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) >> >> MKIMAGEFLAGS_u-boot-spl.kwb = -n $(srctree)/$(CONFIG_SYS_KWD_CONFIG:"%"=%) \ >> - -T kwbimage -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) >> + -T kwbimage -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) \ >> + $(if $(KEYDIR),-k $(KEYDIR)) >> >> MKIMAGEFLAGS_u-boot.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \ >> -R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:"%"=%) -T pblimage >> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig >> index 6e8026b..1ca7b52 100644 >> --- a/arch/arm/mach-mvebu/Kconfig >> +++ b/arch/arm/mach-mvebu/Kconfig >> @@ -1,5 +1,9 @@ >> if ARCH_MVEBU >> >> +config HAVE_MVEBU_EFUSE >> + bool >> + default n >> + >> config ARMADA_32BIT >> bool >> select CPU_V7 >> @@ -21,6 +25,7 @@ config ARMADA_375 >> config ARMADA_38X >> bool >> select ARMADA_32BIT >> + select HAVE_MVEBU_EFUSE > > Do you know if this secure boot support provided in this patch (and > the one before it) also supports the Armada XP SoCs? > I just skimmed the Armada XP secure boot process, and it looks strikingly similar to the Armada 38x one. I haven't looked at the details, but I would tentatively say that the process implemented here should work on Armada XP as well. >> config ARMADA_XP >> bool >> @@ -136,4 +141,19 @@ config SYS_VENDOR >> config SYS_SOC >> default "mvebu" >> >> +config MVEBU_EFUSE >> + bool "Enable eFuse support" >> + default n >> + depends on HAVE_MVEBU_EFUSE > > Is this Kconfig option enabled in your board support patch? I can't > find it there. And could you please add a help text to this option > as well? > We're not using the secure boot in production yet, so it's not enabled in the board for now (we'll most likely activate it in a later revision). And I'll add a help text in v2. >> +config MVEBU_EFUSE_FAKE >> + bool "Fake eFuse access (dry run)" >> + default n >> + depends on MVEBU_EFUSE >> + help >> + This enables a "dry run" mode where eFuses are not really programmed. >> + Instead the eFuse accesses are emulated by writing to and reading >> + from a memory block. >> + This is can be used for testing prog scripts. >> + >> endif >> diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile >> index 65e90c4..d4210af 100644 >> --- a/arch/arm/mach-mvebu/Makefile >> +++ b/arch/arm/mach-mvebu/Makefile >> @@ -27,6 +27,7 @@ ifndef CONFIG_SPL_BUILD >> obj-$(CONFIG_ARMADA_375) += ../../../drivers/ddr/marvell/axp/xor.o >> obj-$(CONFIG_ARMADA_38X) += ../../../drivers/ddr/marvell/a38x/xor.o >> obj-$(CONFIG_ARMADA_XP) += ../../../drivers/ddr/marvell/axp/xor.o >> +obj-$(CONFIG_MVEBU_EFUSE) += efuse.o >> endif # CONFIG_SPL_BUILD >> obj-y+= gpio.o >> obj-y+= m
[U-Boot] [PATCH] driver: fsl-mc: qbman: Add QBMAN 4.1 support
LS2080A SoC family has QBMAN ver 4.0 whereas newer
SoCs like LS2088A, LS1088A has QBMAN ver 4.1
QBMAN ver 4.0 and ver 4.1 supports dqrr size as 4 and 8 respectively.
Add support of
to check QBMAN version based on SoC SVR
update dqrr_size accordingly
update code to support larger dqrr_size
Signed-off-by: Priyanka Jain
Signed-off-by: Prabhakar Kushwaha
---
drivers/net/fsl-mc/dpio/qbman_portal.c | 19 ---
drivers/net/fsl-mc/dpio/qbman_portal.h |5 +++--
drivers/net/fsl-mc/dpio/qbman_private.h | 19 +++
drivers/net/fsl-mc/dpio/qbman_sys.h | 18 ++
4 files changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/net/fsl-mc/dpio/qbman_portal.c
b/drivers/net/fsl-mc/dpio/qbman_portal.c
index 4b64c8a..86dc13d 100644
--- a/drivers/net/fsl-mc/dpio/qbman_portal.c
+++ b/drivers/net/fsl-mc/dpio/qbman_portal.c
@@ -25,7 +25,7 @@
#define QBMAN_CENA_SWP_VDQCR 0x780
/* Reverse mapping of QBMAN_CENA_SWP_DQRR() */
-#define QBMAN_IDX_FROM_DQRR(p) (((unsigned long)p & 0xff) >> 6)
+#define QBMAN_IDX_FROM_DQRR(p) (((unsigned long)p & 0x1ff) >> 6)
/***/
/* Pre-defined attribute codes */
@@ -65,6 +65,7 @@ struct qbman_swp *qbman_swp_init(const struct qbman_swp_desc
*d)
{
int ret;
struct qbman_swp *p = malloc(sizeof(struct qbman_swp));
+ u32 major = 0, minor = 0;
if (!p)
return NULL;
@@ -80,8 +81,20 @@ struct qbman_swp *qbman_swp_init(const struct qbman_swp_desc
*d)
atomic_set(&p->vdq.busy, 1);
p->vdq.valid_bit = QB_VALID_BIT;
p->dqrr.next_idx = 0;
+
+ qbman_version(&major, &minor);
+ if (!major) {
+ printf("invalid qbman version\n");
+ return NULL;
+ }
+
+ if (major >= 4 && minor >= 1)
+ p->dqrr.dqrr_size = QBMAN_VER_4_1_DQRR_SIZE;
+ else
+ p->dqrr.dqrr_size = QBMAN_VER_4_0_DQRR_SIZE;
+
p->dqrr.valid_bit = QB_VALID_BIT;
- ret = qbman_swp_sys_init(&p->sys, d);
+ ret = qbman_swp_sys_init(&p->sys, d, p->dqrr.dqrr_size);
if (ret) {
free(p);
printf("qbman_swp_sys_init() failed %d\n", ret);
@@ -380,7 +393,7 @@ const struct ldpaa_dq *qbman_swp_dqrr_next(struct qbman_swp
*s)
/* There's something there. Move "next_idx" attention to the next ring
* entry (and prefetch it) before returning what we found. */
s->dqrr.next_idx++;
- s->dqrr.next_idx &= QBMAN_DQRR_SIZE - 1; /* Wrap around at 4 */
+ s->dqrr.next_idx &= s->dqrr.dqrr_size - 1;/* Wrap around at dqrr_size */
/* TODO: it's possible to do all this without conditionals, optimise it
* later. */
if (!s->dqrr.next_idx)
diff --git a/drivers/net/fsl-mc/dpio/qbman_portal.h
b/drivers/net/fsl-mc/dpio/qbman_portal.h
index 86e2c3a..97a47aa 100644
--- a/drivers/net/fsl-mc/dpio/qbman_portal.h
+++ b/drivers/net/fsl-mc/dpio/qbman_portal.h
@@ -14,8 +14,8 @@
/* Management command result codes */
#define QBMAN_MC_RSLT_OK 0xf0
-/* TBD: as of QBMan 4.1, DQRR will be 8 rather than 4! */
-#define QBMAN_DQRR_SIZE 4
+#define QBMAN_VER_4_0_DQRR_SIZE 4
+#define QBMAN_VER_4_1_DQRR_SIZE 8
/* - */
@@ -71,6 +71,7 @@ struct qbman_swp {
struct {
uint32_t next_idx;
uint32_t valid_bit;
+ uint8_t dqrr_size;
} dqrr;
};
diff --git a/drivers/net/fsl-mc/dpio/qbman_private.h
b/drivers/net/fsl-mc/dpio/qbman_private.h
index f1f16b8..73bbae3 100644
--- a/drivers/net/fsl-mc/dpio/qbman_private.h
+++ b/drivers/net/fsl-mc/dpio/qbman_private.h
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#define QBMAN_CHECKING
@@ -166,4 +167,22 @@ static inline void dcbz(void *ptr)
#define lwsync()
+void qbman_version(u32 *major, u32 *minor)
+{
+ u32 svr_dev_id;
+
+ /*
+* LS2080A SoC and its personalities has qbman cotroller version 4.0
+* New SoCs like LS2088A, LS1088A has qbman conroller version 4.1
+*/
+ svr_dev_id = get_svr() >> 16;
+ if (svr_dev_id == SVR_DEV_LS2080A) {
+ *major = 4;
+ *minor = 0;
+ } else {
+ *major = 4;
+ *minor = 1;
+ }
+}
+
#include "qbman_sys.h"
diff --git a/drivers/net/fsl-mc/dpio/qbman_sys.h
b/drivers/net/fsl-mc/dpio/qbman_sys.h
index 7a537fb..72d74c5 100644
--- a/drivers/net/fsl-mc/dpio/qbman_sys.h
+++ b/drivers/net/fsl-mc/dpio/qbman_sys.h
@@ -239,16 +239,18 @@ static inline uint32_t qbman_set_swp_cfg(uint8_t
max_fill, uint8_t wn,
{
uint32_t reg;
- reg = e32_uint8_t(20, 3, max_fill) | e32_uint8_t(16, 3, est) |
- e32_uint8_t(12, 2, rpm) | e32_uint8_t(10, 2, dcm) |
- e32_uint8_t(8, 2, epm) | e32_int(5, 1, sd) |
- e32_int(4, 1, sp) | e32_int(3, 1, se) | e32_int(2, 1, dp) |
- e32_int(1, 1
[U-Boot] [PATCH 2/4] mmc: fsl_esdhc: add 'fsl, esdhc' into of_match table
This patch is to add 'fsl,esdhc' into of_match table to support
driver model for QorIQ eSDHC.
Signed-off-by: Yangbo Lu
---
drivers/mmc/fsl_esdhc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index da3a151..0ae1cfd 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -1027,6 +1027,7 @@ static const struct udevice_id fsl_esdhc_ids[] = {
{ .compatible = "fsl,imx6sl-usdhc", },
{ .compatible = "fsl,imx6q-usdhc", },
{ .compatible = "fsl,imx7d-usdhc", },
+ { .compatible = "fsl,esdhc", },
{ /* sentinel */ }
};
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] configs: ls1012a: enable driver model for eSDHC
Enable driver model for eSDHC on ls1012a rdb and qds boards. Signed-off-by: Yangbo Lu --- configs/ls1012aqds_qspi_defconfig | 3 +++ configs/ls1012ardb_qspi_defconfig | 3 +++ 2 files changed, 6 insertions(+) diff --git a/configs/ls1012aqds_qspi_defconfig b/configs/ls1012aqds_qspi_defconfig index 27bccd1..7b015a0 100644 --- a/configs/ls1012aqds_qspi_defconfig +++ b/configs/ls1012aqds_qspi_defconfig @@ -33,6 +33,9 @@ CONFIG_E1000=y CONFIG_PCI=y CONFIG_SYS_NS16550=y CONFIG_DM_SPI=y +CONFIG_DM_MMC=y +CONFIG_DM_MMC_OPS=n +CONFIG_BLK=n CONFIG_FSL_DSPI=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y diff --git a/configs/ls1012ardb_qspi_defconfig b/configs/ls1012ardb_qspi_defconfig index 459682d..d86cb0f 100644 --- a/configs/ls1012ardb_qspi_defconfig +++ b/configs/ls1012ardb_qspi_defconfig @@ -33,6 +33,9 @@ CONFIG_E1000=y CONFIG_PCI=y CONFIG_SYS_NS16550=y CONFIG_DM_SPI=y +CONFIG_DM_MMC=y +CONFIG_DM_MMC_OPS=n +CONFIG_BLK=n CONFIG_FSL_DSPI=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] armv8: ls1012a: add eSDHC nodes
This patch is to add eSDHC nodes for ls1012a.
Signed-off-by: Yangbo Lu
---
arch/arm/dts/fsl-ls1012a.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1012a.dtsi b/arch/arm/dts/fsl-ls1012a.dtsi
index 024527e..f8b341d 100644
--- a/arch/arm/dts/fsl-ls1012a.dtsi
+++ b/arch/arm/dts/fsl-ls1012a.dtsi
@@ -103,5 +103,22 @@
status = "disabled";
};
+ esdhc0: esdhc@156 {
+ compatible = "fsl,esdhc";
+ reg = <0x0 0x156 0x0 0x1>;
+ interrupts = <0 62 0x4>;
+ big-endian;
+ bus-width = <4>;
+ };
+
+ esdhc1: esdhc@158 {
+ compatible = "fsl,esdhc";
+ reg = <0x0 0x158 0x0 0x1>;
+ interrupts = <0 65 0x4>;
+ big-endian;
+ non-removable;
+ bus-width = <4>;
+ };
+
};
};
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] mmc: fsl_esdhc: make GPIO support optional
There would be compiling error as below when enable driver model for esdhc.
undefined reference to `dm_gpio_get_value'
undefined reference to `gpio_request_by_name_nodev'
This patch is to make GPIO support optional with CONFIG_DM_GPIO. Because
all boards of QorIQ platform don't need it and they just check register for
CD/WP status, only some boards of i.MX platform require this.
Signed-off-by: Yangbo Lu
---
drivers/mmc/fsl_esdhc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 9796d39..da3a151 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -104,8 +104,10 @@ struct fsl_esdhc_priv {
struct udevice *dev;
int non_removable;
int wp_enable;
+#ifdef CONFIG_DM_GPIO
struct gpio_desc cd_gpio;
struct gpio_desc wp_gpio;
+#endif
};
/* Return the XFERTYP flags for a given command and data packet */
@@ -687,10 +689,11 @@ static int esdhc_getcd(struct mmc *mmc)
#ifdef CONFIG_DM_MMC
if (priv->non_removable)
return 1;
-
+#ifdef CONFIG_DM_GPIO
if (dm_gpio_is_valid(&priv->cd_gpio))
return dm_gpio_get_value(&priv->cd_gpio);
#endif
+#endif
while (!(esdhc_read32(®s->prsstat) & PRSSTAT_CINS) && --timeout)
udelay(1000);
@@ -967,17 +970,20 @@ static int fsl_esdhc_probe(struct udevice *dev)
priv->non_removable = 1;
} else {
priv->non_removable = 0;
+#ifdef CONFIG_DM_GPIO
gpio_request_by_name_nodev(fdt, node, "cd-gpios", 0,
&priv->cd_gpio, GPIOD_IS_IN);
+#endif
}
priv->wp_enable = 1;
+#ifdef CONFIG_DM_GPIO
ret = gpio_request_by_name_nodev(fdt, node, "wp-gpios", 0,
&priv->wp_gpio, GPIOD_IS_IN);
if (ret)
priv->wp_enable = 0;
-
+#endif
/*
* TODO:
* Because lack of clk driver, if SDHC clk is not enabled,
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/23] sunxi: H3: add DRAM controller single bit delay support
Hi Andre, [...] >>> I wonder if there is value in moving this to device tree with of-platdata? > > While I kind of like the idea of using the DT for this, there are some > issues: > > 1) There is no binding so far for representing the DRAM data. Given the > lacking documentation for the DRAM controller it sounds very hard to > come up with a good binding anyway. Also we can't push this through the > Linux DT binding review, since this is of no interest to the kernel. And > I'd rather avoid making up some dodgy binding just for this. > > There is work underway to improve the DRAM init code and make it more > robust and flexible. Ideally we can use some autodetection and > calibration feature the controller offers to get rid of arbitrary magic > numbers. But this is quite some work ahead and shouldn't block the much > sought after A64 SPL support for now. > > 2) If there is need, we can detect the SoC easily by reading the ID > register and differentiate at runtime. This is probably less code than > pulling in DT bits, also more robust. > >> I think device tree support is unlikely to fit in SPL for sunxi. >> IIRC Andre already mentions the space constraints in his cover letter. > > 3) Yes, adding DT support for the SPL makes it rather big. I think it > breaks the 28K limit that the mksunxiboot tool currently has. This can > (and will) be fixed later, but just for this exercise I'd rather keep it > small, especially as we would use it only for the DRAM code and not for > the device drivers. Take a look at rk3288-firefly if you like. It has an ad-hoc device tree binding (no one has the energy to try to get this into Linux :-). With of-platdata, DT support doesn't actually add any space (or at least very little). There is no libfdt and the only code is that needed to copy data from the of-platdata struct to the normal one. That said, there has to be a benefit, and it's much more desirable to spend the time on this IMO: > > Actually I have a plan to make better use of DT, but not for the SPL. To > a good degree the SPL code mimics the on-SoC boot ROM operation > (accessing storage devices to load code), which has to work with every > board already and thus does not need a board specific DT. > I can elaborate on that if there is interest. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 15/16] pci: layerscape: remove unnecessary legacy code
On 6 December 2016 at 00:03, Zhiqiang Hou wrote: > From: Minghuan Lian > > All Layerscape SoCs have supported new PCIe driver based on DM. > The lagecy PCIe driver code is unused and can be removed. > > Signed-off-by: Minghuan Lian > Signed-off-by: Hou Zhiqiang > --- > V4: > - Generated the patch based on the updated code. > > drivers/pci/pcie_layerscape.c | 496 > > drivers/pci/pcie_layerscape.h | 53 +--- > drivers/pci/pcie_layerscape_fixup.c | 167 > 3 files changed, 1 insertion(+), 715 deletions(-) Nice! Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 09/16] pci: layerscape: add pci driver based on DM
On 6 December 2016 at 00:03, Zhiqiang Hou wrote: > From: Minghuan Lian > > There are more than five kinds of Layerscape SoCs. unfortunately, > PCIe controller of each SoC is a little bit different. In order > to avoid too many macro definitions, the patch addes a new > implementation of PCIe driver based on DM. PCIe dts node is > used to describe the difference. > > Signed-off-by: Minghuan Lian > Signed-off-by: Hou Zhiqiang > --- > V4: > - Separated fixup code to pcie_layerscape_fixup.c. > - Added a header file pcie_layerscape.h. > - Removed board-specified #if, and use the SVR to differentiate in run-time. > - Corrected the indent of #ifs. > - Added comments on some conditions and functions. > > drivers/pci/Kconfig | 8 + > drivers/pci/Makefile| 1 + > drivers/pci/pcie_layerscape.c | 815 > +++- > drivers/pci/pcie_layerscape.h | 191 + > drivers/pci/pcie_layerscape_fixup.c | 354 > 5 files changed, 1079 insertions(+), 290 deletions(-) > create mode 100644 drivers/pci/pcie_layerscape.h > create mode 100644 drivers/pci/pcie_layerscape_fixup.c Reviewed-by: Simon Glass Although I would suggest splitting this out into two patches - one that moves the code and one that changes it. It's really not feasible to reviewed it as is. - Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] Introduce CONFIG_SPL_ABORT_ON_NON_FIT_IMAGE
Hi Andrew, On 5 December 2016 at 17:37, Andrew F. Davis wrote: > On 11/14/2016 06:33 PM, Simon Glass wrote: >> Hi Andrew, >> >> On 14 November 2016 at 15:05, Andrew F. Davis wrote: >>> On 11/14/2016 02:44 PM, Simon Glass wrote: Hi Andrew, On 14 November 2016 at 12:14, Andrew F. Davis wrote: > Introduce CONFIG_SPL_ABORT_ON_NON_FIT_IMAGE. An SPL which define > this will abort image loading if the image is not a FIT image. > > Signed-off-by: Andrew F. Davis > --- > Kconfig | 9 + > common/spl/spl.c | 5 + > 2 files changed, 14 insertions(+) > > diff --git a/Kconfig b/Kconfig > index 1263d0b..eefebef 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -291,6 +291,15 @@ config FIT_IMAGE_POST_PROCESS > injected into the FIT creation (i.e. the blobs would have been > pre- > processed before being added to the FIT image). > > +config SPL_ABORT_ON_NON_FIT_IMAGE We already have CONFIG_IMAGE_FORMAT_LEGACY so how about CONFIG_SPL_IMAGE_FORMAT_LEGACY instead? It can default to y if secure boot is disabled. >>> >>> We also already have CONFIG_SPL_ABORT_ON_RAW_IMAGE on which this is >>> based. If we only disable legacy image support then RAW images should >>> still be allowed, but we will fail early anyway, we will start to need >>> an unmaintainable amount of pre-processor logic to to handle the >>> different image types and what is allowed/not allowed. >>> >>> Even worse some boot modes don't seem to support FIT images (net, >>> onenand) so these will alway expect legacy to work. Right now we simply >>> have to disable these modes. >> >> IMO CONFIG_SPL_ABORT_ON_RAW_IMAGE should become a positive option, to >> fit in with the legacy format. Otherwise we'll get very confused I >> think. >> > > I'm not sure what you are suggesting here, would you like > > CONFIG_SPL_SUPPORT_RAW_IMAGE > CONFIG_SPL_SUPPORT_LEGACY_IMAGE > CONFIG_SPL_SUPPORT_FIT_IMAGE > > And then we disable as needed? I'm not sure this will work in our case, > as a new image type may be introduced and enabled by default, this will > break our board security until we discover this and disabled it. The > benefit of a negative option for us is that we can specify we *only* > allow FIT, then it will be obvious to someone adding a new image type > they will not meet this check and should not put code outside this block. I don't think we add new image types often, and they should default to n just as we do for U-Boot proper. Although something odd has happened with DISABLE_IMAGE_LEGACY. his should of thing should be caught in a security review. Also you could add something to print a warning if secure boot is enabled but insecure boot options are available? Perhaps that should be another option, and default to y? It's just that it is really hard to deal with multiple negative options, so best avoided if we can. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] test/py: Create tests for ext4 and fat testing on sandbox
On 4 December 2016 at 19:52, Stefan Brüns wrote: > From: Stefan Brüns > > The following checks are currently implemented: > 1. listing a directory > 2. verifying size of a file > 3. veryfying md5sum for a file region > 4. reading the beginning of a file > > Signed-off-by: Stefan Brüns > --- > test/py/tests/test_fs.py | 357 > +++ > 1 file changed, 357 insertions(+) > create mode 100644 test/py/tests/test_fs.py Reviewed-by: Simon Glass Great to get this conversion going, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
Hi Rick, On 5 December 2016 at 19:56, Rick Bronson wrote: > Hi Heiko, > > Thanks again for the help. > > Been testing the RK3288 Ethernet and it works pretty good. One > thing I was wondering about was that I seemed to have to have: > > CONFIG_NET_RANDOM_ETHADDR=y > > or I get: > > Error: ethernet@ff29 address not set. > > Is there a better way? > > Another issue we were having is when attached to a Gigabit > switch/router it seemed to have a lot of trouble negociating and would > fail often. So, for the time being, I've hooked it to a 100MBit > router. Haven't seen any problems with that. Just wondered if you > have observed this behavior? Yes I think Heiko has seen this. I'm hoping to try it out property myself (my testing on 1GBit has bee limited... - Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uefi: x86: uboot as uefi payload
Hi Markus, On 5 December 2016 at 11:20, Markus Valentin wrote: > Hi Simon, > On Sun, 2016-12-04 at 23:24 -0700, Simon Glass wrote: >> Hi Markus, >> >> On 1 December 2016 at 01:58, Markus Valentin wrote: >> > >> > Hi Simon, >> > Am Mittwoch, den 30.11.2016, 19:20 -0700 schrieb Simon Glass: >> > > >> > > Hi Markus, >> > > >> > > On 30 November 2016 at 04:32, Markus Valentin wrote: >> > > > >> > > > >> > > > Hi, >> > > > >> > > > im trying to run u-boot as uefi-payload for qemu this works totally >> > > > fine. >> > > > >> > > > My real target is a Minnowboard Turbot. I did use the >> > > > minnowmax_defconfig enabled CONFIG_EFI, CONFIG_EFI_STUB and >> > > > CONFIG_EFI_STUB_64BIT. The Board has the latest uefi by Intel >> > > > installed(0.93, X64). >> > > > >> > > > When i load U-Boot as payload for the board-uefi the efi_main >> > > > function >> > > > gets executed but the call to "cpu_call32" seems to get stuck ( i >> > > > think >> > > > its at the "retf" arch/x86/cpu/call32.S:37). >> > > > >> > > > Debuglog: >> > > > >> > > > Shell> u-boot-payload_64.efi >> > > > U-Boot EFI Payload >> > > > gdt: 0047, addr: 784fd570 >> > > > 00: >> > > > 08: 00cf9200 >> > > > 10: 00af9a00 >> > > > 18: 00cf9300 >> > > > 20: 00cf9a00 >> > > > 28: >> > > > 30: 00cf9200 >> > > > 38: 00af9b00 >> > > > 40: >> > > > 32-bit code segment: 20 >> > > > page_table: 79313000 >> > > > EFI table at 78787018 size 0760 >> > > > >> > > > Does anyone have experiences with this issue or with running u-boot >> > > > as >> > > > uefi-64 payload at all? >> > > >> > > I have used this on the original Minnowboard and it is used on some >> > > broadwell platforms. >> > Great so i should be able to get it working too. >> > > >> > > >> > > I did hit a similar problem due to the 'ret' not generating the right >> > > instruction. I thought it was fixed but I suppose it is not >> > > impossible >> > > that the gcc toolchains might generate different op codes in >> > > different >> > > situations. >> > > >> > > Which toolchain are you using? >> > Im using the gcc6 from Debian/testing,(6.2.0-13) and glibc6 2.24-5. >> > >> > Can you suggest a Toolchain? Mine is probably too "current"? >> >> I was using 4.9.0 now but I'm not sure if that is what I tested with. >> I'll try it again when I get a chance, but it will be a week or so as >> I am travelling. > > I was not a matter of the the toolchain my SYS_TEXT_BASE was wrong > (0xfff0) for unknown reason. > > Once i created my own defconfig-file which sets the required KConfig- > variables, the default from board/intel/minnowmax/Kconfig gets > properly applied I did use menuconfig before which did somehow not > put the changes to the .config file. That's the base used for U-Boot running from ROM. I thought it would be relocatable to the text base would not matter, but indeed, that value seems more like a ROM value than a RAM value. Anyway I'm please you have it running. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC
Hi Oliver,
On 5 December 2016 at 03:28, Olliver Schinagl wrote:
> Hey Simon,
>
>
>
> On 05-12-16 07:24, Simon Glass wrote:
>>
>> Hi Oliver,
>>
>> On 2 December 2016 at 03:16, Olliver Schinagl wrote:
>>>
>>> Hey Joe,
>>>
>>>
>>>
>>> On 30-11-16 21:40, Joe Hershberger wrote:
On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl
wrote:
>
> This patch adds a method for the board to set the MAC address if the
> environment is not yet set. The environment based MAC addresses are not
> touched, but if the fdt has an alias set, it is parsed and put into the
> environment.
>
> E.g. The environment contains ethaddr and eth1addr, and the fdt
> contains
> an ethernet1 nothing happens. If the fdt contains ethernet2 however, it
> is parsed and inserted into the environment as eth2addr.
>
> Signed-off-by: Olliver Schinagl
> ---
>common/fdt_support.c | 8 +++-
>1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index c34a13c..f127392 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -465,6 +465,11 @@ int fdt_fixup_memory(void *blob, u64 start, u64
> size)
> return fdt_fixup_memory_banks(blob, &start, &size, 1);
>}
>
> +__weak int board_get_enetaddr(const int i, unsigned char *mac_addr)
Ugh. This collides with a function in board/v38b/ethaddr.c and in
board/intercontrol/digsy_mtc/digsy_mtc.c
Also, it's so generic, and only gets called by the fdt fixup stuff...
This function should probably be named in such a way that its
association with fdt is clear.
>>>
>>> I did not notice that, sorry! But naming suggestions are welcome :)
>>>
>>> Right now, I use it in two unrelated spots however.
>>>
>>> from the fdt as seen above and in a subclass driver (which will come up
>>> for
>>> review) as suggested by Simon.
>>>
>>> There I do:
>>>
>>> +static int sunxi_gmac_eth_read_rom_hwaddr(struct udevice *dev)
>>> +{
>>> + struct eth_pdata *pdata = dev_get_platdata(dev);
>>> +
>>> + return board_get_enetaddr(dev->seq, pdata->enetaddr);
>>> +}
>>> +
>>> const struct eth_ops sunxi_gmac_eth_ops = {
>>> .start = designware_eth_start,
>>> .send = designware_eth_send,
>>> @@ -102,6 +110,7 @@ const struct eth_ops sunxi_gmac_eth_ops = {
>>> .free_pkt = designware_eth_free_pkt,
>>> .stop = designware_eth_stop,
>>> .write_hwaddr = designware_eth_write_hwaddr,
>>> + .read_rom_hwaddr= sunxi_gmac_eth_read_rom_hwaddr,
>>> };
>>>
>>> which is completly unrelated to the fdt.
>>>
>>> So naming suggestion or overal suggestion how to handle this nice and
>>> generically?
>>>
>>> Based from the name however I would think that all board_get_enetaddr's
>>> work
>>> the same however so should have been interchangeable? Or was that silly
>>> thinking?
>>
>> Would it be possible to use a name without 'board' in it? I think this
>> / hope is actually sunxi-specific code, not board-specific?
>
> You are actually correct, we take the serial number of the SoC (sunxi
> specific) and generate a serial/MAC from it. So nothing to do with the
> board. So I can just name it sunxi_gen_enetaddr(). Would that be then (much)
> better?
>
> The reason why I went to 'board' with my mind, is because a) the original
> mac gen code and b) the location was in board/sunxi/board.c. I think it is
> thus also sensible to move it out of board/sunxi/board.c as indeed, it has
> nothing to do with board(s).
That sounds good to me - and you should be able to call it directly
from the driver and avoid any weak functions, right?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] test/py: Allow to pass u_boot_log instead of console for run_and_log
Hi Stefan, On 4 December 2016 at 19:52, Stefan Brüns wrote: > The runner actually has no console dependency, only on the log provided > by the console. Accept both u_boot_console or a multiplexed_log. In that case I wonder if it would be better to change it to a log, only? I will leave it for Stephen to comment on this. > > Signed-off-by: Stefan Brüns > --- > test/py/u_boot_utils.py | 20 ++-- > 1 file changed, 14 insertions(+), 6 deletions(-) > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/6] arm64: mvebu: pinctrl: Add pin control driver for A8K family
On 5 December 2016 at 05:16, wrote: > From: Konstantin Porotchkin > > Add a DM port of Marvell pin control driver. > The A8K SoC family contains several silicone dies interconnected > in a single package. Every die is normally equipped with its own > pin controller unit. > There are 2 pin controllers in A70x0 SoC and 3 in A80x0 SoC. > > Changes for v3: > - Extend the Kconfig help for pin control driver > > Signed-off-by: Konstantin Porotchkin > Cc: Simon Glass > Cc: Stefan Roese > Cc: Nadav Haklai > Cc: Neta Zur Hershkovits > Cc: Omri Itach > Cc: Igal Liberman > Cc: Haim Boot > Cc: Hanna Hawa > --- > arch/arm/include/asm/arch-armada8k/soc-info.h | 17 ++ > .../pinctrl/marvell,armada-apn806-pinctrl.txt | 25 ++ > .../pinctrl/marvell,armada-cp110-pinctrl.txt | 270 > + > .../pinctrl/marvell,mvebu-pinctrl.txt | 113 + > drivers/pinctrl/Kconfig| 1 + > drivers/pinctrl/Makefile | 1 + > drivers/pinctrl/mvebu/Kconfig | 16 ++ > drivers/pinctrl/mvebu/Makefile | 7 + > drivers/pinctrl/mvebu/pinctrl-mvebu.c | 179 ++ > drivers/pinctrl/mvebu/pinctrl-mvebu.h | 31 +++ > 10 files changed, 660 insertions(+) > create mode 100644 arch/arm/include/asm/arch-armada8k/soc-info.h > create mode 100644 > doc/device-tree-bindings/pinctrl/marvell,armada-apn806-pinctrl.txt > create mode 100644 > doc/device-tree-bindings/pinctrl/marvell,armada-cp110-pinctrl.txt > create mode 100644 doc/device-tree-bindings/pinctrl/marvell,mvebu-pinctrl.txt > create mode 100644 drivers/pinctrl/mvebu/Kconfig > create mode 100644 drivers/pinctrl/mvebu/Makefile > create mode 100644 drivers/pinctrl/mvebu/pinctrl-mvebu.c > create mode 100644 drivers/pinctrl/mvebu/pinctrl-mvebu.h > I think I already reviewed this, but just in case: Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/17] dm: Add callback to modify the device tree
Hi Mario,
On 5 December 2016 at 10:32, Mario Six wrote:
> Hi Simon,
>
> On Mon, Dec 5, 2016 at 7:24 AM, Simon Glass wrote:
>> Hi,
>>
>> On 1 December 2016 at 01:39, Stefan Roese wrote:
>>> (Adding Simon and Maxim to Cc)
>>>
>>> On 23.11.2016 16:12, Mario Six wrote:
Certain boards come in different variations by way of utilizing daughter
boards, for example. These boards might contain additional chips, which
are added to the main board's busses, e.g. I2C.
The device tree support for such boards would either, quite naturally,
employ the overlay mechanism to add such chips to the tree, or would use
one large default device tree, and delete the devices that are actually
not present.
Regardless of approach, even on the U-Boot level, a modification of the
device tree is a prerequisite to have such modular families of boards
supported properly.
Therefore, we add an option to make the U-Boot device tree (the actual
copy later used by the driver model) writeable, and add a callback
method that allows boards to modify the device tree at an early stage,
at which, hopefully, also the application of device tree overlays will
be possible.
Signed-off-by: Mario Six
>>>
>>>
>>> I didn't follow DT overlay lately closely especially not in U-Boot.
>>> Simon, Maxim could you please take a look at this patch and comment
>>> on its necessity?
>>>
>>>
---
common/board_f.c | 3 +++
dts/Kconfig | 10 ++
include/asm-generic/global_data.h | 4
include/common.h | 1 +
4 files changed, 18 insertions(+)
diff --git a/common/board_f.c b/common/board_f.c
index 4b74835..cda5aae 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -1034,6 +1034,9 @@ static init_fnc_t init_sequence_f[] = {
#ifdef CONFIG_SYS_EXTBDINFO
setup_board_extra,
#endif
+#ifdef CONFIG_OF_BOARD_FIXUP
+ board_fix_fdt,
+#endif
>>
>> Can you add documentation for this somewhere? E.g. in the driver model
>> readme?
>>
>
> OK, I'll document the feature in v2.
>
INIT_FUNC_WATCHDOG_RESET
reloc_fdt,
setup_reloc,
diff --git a/dts/Kconfig b/dts/Kconfig
index 4b7d8b1..3f64eda 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -14,6 +14,16 @@ config OF_CONTROL
This feature provides for run-time configuration of U-Boot
via a flattened device tree.
+config OF_BOARD_FIXUP
+ bool "Board-specific manipulation of Device Tree"
+ help
+ In certain circumstances it is necessary to be able to modify
+ U-Boot's device tree (e.g. to delete device from it). This
option
+ make the Device Tree writeable and provides a board-specific
+ "board_fix_fdt" callback (called during pre-relocation time),
which
+ enables the board initialization to modifiy the Device Tree. The
+ modified copy is subsequently used by U-Boot after relocation.
+
config SPL_OF_CONTROL
bool "Enable run-time configuration via Device Tree in SPL"
depends on SPL && OF_CONTROL
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index e02863d..f566186 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -69,7 +69,11 @@ typedef struct global_data {
struct udevice *timer; /* Timer instance for Driver Model
*/
#endif
+#ifdef CONFIG_OF_BOARD_FIXUP
+ void *fdt_blob; /* Our device tree, NULL if none
*/
+#else
const void *fdt_blob; /* Our device tree, NULL if none
*/
+#endif
>>
>> Can we keep it as const and just use a cast when it needs to change?
>> You could add a function which returns a writable pointer.
>>
>
> Having the pointer globally writable has the advantage that you can get a
> writable pointer wherever you need it and don't have to pass it around, but
> separating the parts where the pointer is writable from the ones where it is
> not is probably a good idea. Will fix in v2.
>
>>
void *new_fdt; /* Relocated FDT */
unsigned long fdt_size; /* Space reserved for relocated
FDT */
struct jt_funcs *jt;/* jump table */
diff --git a/include/common.h b/include/common.h
index a8d833b..293ce23 100644
--- a/include/common.h
+++ b/include/common.h
@@ -502,6 +502,7 @@ extern ssize_t spi_write (uchar *, int, uchar *, int);
/* $(BOARD)/$(BOARD).c */
int board_early_init_f (void);
+int board_fix_fdt (void);
>>
>> Comment please. Perhaps it should pass a writable fdt pointer?
>>
>
>
Re: [U-Boot] [PATCH v4 2/2] splash: add support for loading splash from a FIT image
On 5 December 2016 at 02:36, Tomas Melin wrote: > Enable support for loading a splash image from within a FIT image. > The image is assumed to be generated with mkimage -E flag to hold > the data external to the FIT. > > Signed-off-by: Tomas Melin > --- > > Changes in v4: > - Added missing changelog > > Changes in v3: > - Add documentation to README.splashprepare > - Change printf() to debug() > - Coding style fixes > > Changes in v2: > - Add helper functions to image-fit.c for getting required FIT data fields > - Add comments > > common/image-fit.c | 48 > common/splash_source.c | 71 > > doc/README.splashprepare | 15 ++ > include/image.h | 4 +++ > include/splash.h | 5 ++-- > 5 files changed, 136 insertions(+), 7 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] splash: sort include files
On 5 December 2016 at 02:36, Tomas Melin wrote: > Sort include files in accordance to u-boot coding style. > > Signed-off-by: Tomas Melin > --- > > Changes in v4: > - Added missing changelog > > Changes in v3: > - Change patch order so that include sort patch comes prior to adding > new include > > Changes in v2: > - Add separate patch for sorting include files > > common/splash_source.c | 13 +++-- > 1 file changed, 7 insertions(+), 6 deletions(-) Reviewed-by: Simon Glass Note: It is 'U-Boot', not 'u-boot' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 02/16] dm: pci: return the real controller in pci_bus_to_hose()
Hi York, > -Original Message- > From: york sun > Sent: 2016年12月7日 0:23 > To: Z.Q. Hou ; u-boot@lists.denx.de; > albert.u.b...@aribaud.net; Prabhakar Kushwaha > ; alison.w...@freescale.com; Sumit Garg > ; Ruchika Gupta ; > saksham.j...@nxp.freescale.com; M.H. Lian ; > s...@chromium.org; bmeng...@gmail.com; Mingkai Hu > > Subject: Re: [PATCHv4 02/16] dm: pci: return the real controller in > pci_bus_to_hose() > > On 12/05/2016 09:16 PM, Zhiqiang Hou wrote: > > From: Minghuan Lian > > > > for the legacy PCI driver, the function pci_bus_to_hose() returns the > > real PCIe controller. To keep consistency, this function is changed to > > return the PCIe controller pointer of the root bus instead of the > > current PCIe bus. > > > > Signed-off-by: Minghuan Lian > > Signed-off-by: Hou Zhiqiang > > --- > > V4: > > - No change > > > > Zhiqiang, > > When you send a new set with some patches _unchanged_, you can add the > review signature for them, so the reviewers don't have to send another one. > This will help me to identify which one I should pay more attention. Got it, thanks a lot for the suggestion! Thanks, Zhiqiang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] mmc: complete the unfinished move of CONFIG_MMC
Hi Tom, 2016-12-06 22:03 GMT+09:00 Tom Rini : > >> I tried your suggestion. >> It is true that 625 touched defconfigs were decreased to 389, >> but do you think this is a really good idea? >> >> Theoretically, nothing of MMC >> is related to ARM, PowerPC, Sandbox. >> >> I think this is shortening defconfigs >> for the purpose of shortening. > > Yes, it is for the purpose of shortening the configs. > >> BTW, do you know that >> Kbuild subsystem is discussing a new keyword "imply" ? >> >> https://patchwork.kernel.org/patch/9422463/ >> >> >> I am thinking it, if accepted, will be a better solution than >> such unrelated "depends on " or "depends on ". > > Adding "imply" could help here I think, yes. The problem is that I want > to make the defaults in Kconfig produce a reasonable defconfig rather > than require each new defconfig to require a lot of information to > produce a reasonable binary. Looking at the imply examples I think that > yes, we could probably get away with doing things like: > arch/Kconfig: > config ARM > bool "ARM Architecture" > ... > imply MMC > imply DISPLAY_BOARDINFO > imply DISPLAY_CPUINFO > Yes, this looks better. For now, I will go with "default ARM || PPC || SANDBOX". I will send v2. Once the "imply" is merged in the kernel, we can immediately sync with it. Then, it would be easy to convert "default" to "imply". Oh, I found a more crazy default. The "imply" may be helpful for cleanups. config SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR bool "MMC raw mode: by sector" depends on SPL default y if ARCH_SUNXI || ARCH_DAVINCI || ARCH_UNIPHIER ||ARCH_MX6 || \ ARCH_ROCKCHIP || ARCH_MVEBU || ARCH_SOCFPGA || \ ARCH_AT91 || ARCH_ZYNQ || ARCH_KEYSTONE || OMAP34XX || \ OMAP44XX || OMAP54XX || AM33XX || AM43XX help Use sector number for specifying U-Boot location on MMC/SD in raw mode. -- 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 0/6] dm: i2c: Set a timeline for conversion of i2c drivers
On Tuesday, 6 December 2016, Jaehoon Chung wrote: > Hi Simon, > > On 11/23/2016 10:34 PM, Simon Glass wrote: > > Driver-model I2C support was added about 2 years ago. So far a little > over > > half of the driveres have been converted. This series sets a timeline for > > conversion of the rest by June next year. > > > > The Samsung I2C driver was one of the first converted, but some boards > > still remain using the old subsystem. This series converts these over in > > an experimental way: disabling code that uses the old framework. This > > should provide more time for the maintainers to take action while > allowing > > the conversion to be completed. > > About using the old framework, i will discuss with Minkyu. > After that, if it needs, i or my colleague will change to DM. Yes! please : ) I will contact you. Thanks, Minkyu Kang > > Best Regards, > Jaehoon Chung > > > > > > > Simon Glass (6): > > arm: exynos: i2c: Convert exynos boards to use DM_I2C > > arm: samsung: Convert s5p_goni and smdkc100 to DM_I2C > > samsung: i2c: Drop old code from I2C driver > > samsung: i2c: Split the high-speed I2C code into a new driver > > dm: i2c: Add a note to I2C drivers which need conversion > > dm: Add timeline and guide for porting I2C drivers > > > > arch/arm/Kconfig |2 + > > board/samsung/common/misc.c |4 + > > board/samsung/goni/goni.c|7 +- > > board/samsung/trats/trats.c | 20 +- > > board/samsung/trats2/trats2.c| 18 +- > > board/samsung/universal_c210/universal.c | 22 +- > > configs/origen_defconfig |1 + > > doc/driver-model/i2c-howto.txt | 56 ++ > > drivers/i2c/Makefile |2 +- > > drivers/i2c/adi_i2c.c|3 + > > drivers/i2c/davinci_i2c.c|3 + > > drivers/i2c/exynos_hs_i2c.c | 561 +++ > > drivers/i2c/fti2c010.c |3 + > > drivers/i2c/ihs_i2c.c|3 + > > drivers/i2c/kona_i2c.c |3 + > > drivers/i2c/lpc32xx_i2c.c|3 + > > drivers/i2c/pca9564_i2c.c|3 + > > drivers/i2c/ppc4xx_i2c.c |3 + > > drivers/i2c/rcar_i2c.c |3 + > > drivers/i2c/s3c24x0_i2c.c| 1136 > +- > > drivers/i2c/s3c24x0_i2c.h| 22 + > > drivers/i2c/sh_i2c.c |3 + > > drivers/i2c/sh_sh7734_i2c.c |3 + > > drivers/i2c/soft_i2c.c |3 + > > drivers/i2c/tsi108_i2c.c |3 + > > drivers/i2c/zynq_i2c.c |3 + > > include/configs/s5p_goni.h | 19 - > > include/configs/s5pc210_universal.h | 19 - > > include/configs/trats.h | 30 - > > include/configs/trats2.h | 33 - > > 30 files changed, 752 insertions(+), 1242 deletions(-) > > create mode 100644 doc/driver-model/i2c-howto.txt > > create mode 100644 drivers/i2c/exynos_hs_i2c.c > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- Thanks. Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/10] arm: socfpga: arria10: Added miscellaneous drivers for Arria10
On 12/06/2016 11:26 PM, dinguyen wrote: > On Tue, 6 Dec 2016, Chee Tien Fong wrote: > >> From: Tien Fong Chee >> >> The drivers is restructured such common functions, gen5 functions, >> and arria10 functions are moved to misc.c, misc_gen5 and misc_arria10 >> respectively. >> >> Signed-off-by: Tien Fong Chee >> Cc: Marek Vasut >> Cc: Dinh Nguyen >> Cc: Chin Liang See >> Cc: Tien Fong >> --- >> arch/arm/mach-socfpga/Makefile|4 +- >> arch/arm/mach-socfpga/include/mach/misc.h | 25 ++ >> arch/arm/mach-socfpga/misc.c | 429 >> +--- >> arch/arm/mach-socfpga/misc_arria10.c | 111 >> arch/arm/mach-socfpga/misc_gen5.c | 363 >> 5 files changed, 517 insertions(+), 415 deletions(-) >> create mode 100644 arch/arm/mach-socfpga/include/mach/misc.h >> create mode 100644 arch/arm/mach-socfpga/misc_arria10.c >> create mode 100644 arch/arm/mach-socfpga/misc_gen5.c >> > > The previous patches in this series applied to Marek's 01-arria10 branch, > but this patch does not apply at all: > > error: patch failed: arch/arm/mach-socfpga/misc.c:361 > error: arch/arm/mach-socfpga/misc.c: patch does not apply > > Also, on the next revision, please add -C to git format-patch. I was tempted to discard that arria 10 patchset from the tree, I've been trying to keep it kinda in sync, but it's probably broken. If you plan to submit A10, just start on u-boot/master and -- if we all agree -- I'll discard the 01-arria10 branch. The current situation is chaos. -- 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 07/10] arm: socfpga: arria10: Added miscellaneous drivers for Arria10
On Tue, 6 Dec 2016, Chee Tien Fong wrote: > From: Tien Fong Chee > > The drivers is restructured such common functions, gen5 functions, > and arria10 functions are moved to misc.c, misc_gen5 and misc_arria10 > respectively. > > Signed-off-by: Tien Fong Chee > Cc: Marek Vasut > Cc: Dinh Nguyen > Cc: Chin Liang See > Cc: Tien Fong > --- > arch/arm/mach-socfpga/Makefile|4 +- > arch/arm/mach-socfpga/include/mach/misc.h | 25 ++ > arch/arm/mach-socfpga/misc.c | 429 +--- > arch/arm/mach-socfpga/misc_arria10.c | 111 > arch/arm/mach-socfpga/misc_gen5.c | 363 > 5 files changed, 517 insertions(+), 415 deletions(-) > create mode 100644 arch/arm/mach-socfpga/include/mach/misc.h > create mode 100644 arch/arm/mach-socfpga/misc_arria10.c > create mode 100644 arch/arm/mach-socfpga/misc_gen5.c > The previous patches in this series applied to Marek's 01-arria10 branch, but this patch does not apply at all: error: patch failed: arch/arm/mach-socfpga/misc.c:361 error: arch/arm/mach-socfpga/misc.c: patch does not apply Also, on the next revision, please add -C to git format-patch. Dinh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 7/9] video: Allow board hook before video init
On Wed, Nov 23, 2016 at 07:21:07PM -0700, Simon Glass wrote: > Hi Maxime, > > On 22 November 2016 at 05:41, Maxime Ripard > wrote: > > Hi Simon, > > > > On Mon, Nov 14, 2016 at 01:44:45PM -0700, Simon Glass wrote: > >> Hi Maxime, > >> > >> On 14 November 2016 at 13:24, Maxime Ripard > >> wrote: > >> > Hi Simon, > >> > > >> > On Fri, Nov 11, 2016 at 09:17:28AM -0700, Simon Glass wrote: > >> >> Hi Maxime, > >> >> > >> >> On 8 November 2016 at 03:19, Maxime Ripard > >> >> wrote: > >> >> > Some boards might need to some additional setup right before > >> >> > initialising > >> >> > the video console. > >> >> > > >> >> > Add some hook to allow that. > >> >> > >> >> Instead of this, can you use driver model (UCLASS_VIDEO)? > >> > > >> > I don't really know the device model that well, hence 'm not really > >> > sure how would that help. Can a board register a hook to be called > >> > before a driver is probed? > >> > >> My suggest would be that the driver can do whatever is required. What > >> is the board-specific code actually wanting to do? > > > > We need to adjust the video-mode environment variable that is going to > > be used in the driver's initialisation. We're doing that by > > identifying which daughter board is attached, and then setting that > > value according to the display output we want to use. > > > > So we need some hook that would run between the environment > > initialisation and the video driver's init. > > As an example of how you might pass platform data to the video driver, > see board_init() in gurnard.c. That's very useful, thanks! Can you also postpone the probe of one driver, or at least defer a driver's probe until some other is done? The way we identify the daughter boards also rely on some driver in the device model (a 1-Wire EEPROM, connected on a GPIO, both of them also being part of the device model), so we need to defer the video driver probe until both of them have been probed and accessed. Thanks! 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] mtd: spi: don't return -1 when scan succeed
On Mon, Dec 5, 2016 at 7:09 PM, Fabien Parent wrote: > In spi_flash_scan, 'ret' is initialled to -1, but 'ret' is not always > used to store a return value, in that case, even when the function > succeed, an error (-1) will be returned. > Lets just return 0 if we hit the end of the function. > > Signed-off-by: Fabien Parent Applied to u-boot-spi/master 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 v3] spi: Add error checking for invalid bus widths
On Mon, Dec 5, 2016 at 7:24 AM, Simon Glass wrote:
> Hi Jagan,
>
> On 1 December 2016 at 05:45, Jagan Teki wrote:
>> On Wed, Nov 30, 2016 at 8:30 AM, Simon Glass wrote:
>>> At present an invalid bus width prints a message but does not return an
>>> error. This is the opposite of the correct behaviour. Adjust it to avoid
>>> code bloat in the common case, and avoid hard-to-debug failure in the
>>> uncommon case.
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>>
>>> Changes in v3:
>>> - Display an error in U-Boot proper, but then continue
>>> - Drop patches previously applied
>>>
>>> drivers/spi/spi-uclass.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
>>> index f59a701..1ab5b75 100644
>>> --- a/drivers/spi/spi-uclass.c
>>> +++ b/drivers/spi/spi-uclass.c
>>> @@ -418,7 +418,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int
>>> node,
>>> mode |= SPI_TX_QUAD;
>>> break;
>>> default:
>>> - error("spi-tx-bus-width %d not supported\n", value);
>>> + warn_non_spl("spi-tx-bus-width %d not supported\n", value);
>>
>> I thought in SPL it will reverse like debug and return by error, make sense?
>
> Sorry I don't understand this comment. The intent here is to:
>
> - do nothing in SPL
> - warn in U-Boot proper with printf()
>
> Are you saying that it should use debug() in SPL?
I though SPL should return error, unlike U-Boot. So-that SPL should
use proper bus-width that will eventually fix the dt.
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 v3 00/11] SF: Cadence QSPI driver fixes and clean up
On Tue, Nov 29, 2016 at 1:58 PM, Phil Edworthy wrote: > This series has fixes, patches to clean the code up, and add support for > specifying the sampling edge. > > Main changes in v3: > 1. Added "spi: cadence_qspi: Use spi mode at the point it is needed" to > address comments for SPI pol/phase code. > 2. "spi: cadence_qspi: Support specifying the sample edge used" has been > split into 3 separate patches. > > > Phil Edworthy (11): > spi: cadence_qspi: Fix clearing of pol/pha bits > spi: cadence_qspi: Fix baud rate calculation > spi: cadence_qspi: Better debug information on the SPI clock rate > spi: cadence_qspi: Use #define for bits instead of bit shifts > spi: cadence_qspi: Clean up the #define names > spi: cadence_qspi: Use spi mode at the point it is needed > spi: cadence_qspi: Remove returns from end of void functions > spi: cadence_qspi: Fix CS timings > spi: cadence_qspi: Move DT prop code to match layout Applied to u-boot-spi/master 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
[U-Boot] [PATCH 2/3] udoo_neo: Add PFUZE300 PMIC support
UDOO Neo boards has a PFUZE300 connected to I2C1 bus.
Tested on a UDOO Neo Full with "pmic PFUZE3000 dump" command.
Signed-off-by: Breno Lima
---
board/udoo/neo/neo.c | 143 +
include/configs/udoo_neo.h | 13 +
2 files changed, 156 insertions(+)
diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c
index cfeed6f..ad7452c 100644
--- a/board/udoo/neo/neo.c
+++ b/board/udoo/neo/neo.c
@@ -19,10 +19,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -41,6 +45,11 @@ enum {
PAD_CTL_PUS_22K_UP | PAD_CTL_SPEED_LOW | \
PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+#define I2C_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
+ PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
+ PAD_CTL_ODE)
+
#define WDOG_PAD_CTRL (PAD_CTL_PUE | PAD_CTL_PKE | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm)
@@ -56,6 +65,136 @@ int dram_init(void)
return 0;
}
+#ifdef CONFIG_SYS_I2C_MXC
+#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
+/* I2C1 for PMIC */
+static struct i2c_pads_info i2c_pad_info1 = {
+ .scl = {
+ .i2c_mode = MX6_PAD_GPIO1_IO00__I2C1_SCL | PC,
+ .gpio_mode = MX6_PAD_GPIO1_IO00__GPIO1_IO_0 | PC,
+ .gp = IMX_GPIO_NR(1, 0),
+ },
+ .sda = {
+ .i2c_mode = MX6_PAD_GPIO1_IO01__I2C1_SDA | PC,
+ .gpio_mode = MX6_PAD_GPIO1_IO01__GPIO1_IO_1 | PC,
+ .gp = IMX_GPIO_NR(1, 1),
+ },
+};
+#endif
+
+#ifdef CONFIG_POWER
+int power_init_board(void)
+{
+ struct pmic *p;
+ int ret;
+ unsigned int reg, rev_id;
+
+ ret = power_pfuze3000_init(PFUZE3000_I2C_BUS);
+ if (ret)
+ return ret;
+
+ p = pmic_get("PFUZE3000");
+ ret = pmic_probe(p);
+ if (ret)
+ return ret;
+
+ pmic_reg_read(p, PFUZE3000_DEVICEID, ®);
+ pmic_reg_read(p, PFUZE3000_REVID, &rev_id);
+ printf("PMIC: PFUZE3000 DEV_ID=0x%x REV_ID=0x%x\n", reg, rev_id);
+
+ /* disable Low Power Mode during standby mode */
+ pmic_reg_read(p, PFUZE3000_LDOGCTL, ®);
+ reg |= 0x1;
+ ret = pmic_reg_write(p, PFUZE3000_LDOGCTL, reg);
+ if (ret)
+ return ret;
+
+ ret = pmic_reg_write(p, PFUZE3000_SW1AMODE, 0xc);
+ if (ret)
+ return ret;
+
+ ret = pmic_reg_write(p, PFUZE3000_SW1BMODE, 0xc);
+ if (ret)
+ return ret;
+
+ ret = pmic_reg_write(p, PFUZE3000_SW2MODE, 0xc);
+ if (ret)
+ return ret;
+
+ ret = pmic_reg_write(p, PFUZE3000_SW3MODE, 0xc);
+ if (ret)
+ return ret;
+
+ /* set SW1A standby voltage 0.975V */
+ pmic_reg_read(p, PFUZE3000_SW1ASTBY, ®);
+ reg &= ~0x3f;
+ reg |= PFUZE3000_SW1AB_SETP(9750);
+ ret = pmic_reg_write(p, PFUZE3000_SW1ASTBY, reg);
+ if (ret)
+ return ret;
+
+ /* set SW1B standby voltage 0.975V */
+ pmic_reg_read(p, PFUZE3000_SW1BSTBY, ®);
+ reg &= ~0x3f;
+ reg |= PFUZE3000_SW1AB_SETP(9750);
+ ret = pmic_reg_write(p, PFUZE3000_SW1BSTBY, reg);
+ if (ret)
+ return ret;
+
+ /* set SW1A/VDD_ARM_IN step ramp up time from 16us to 4us/25mV */
+ pmic_reg_read(p, PFUZE3000_SW1ACONF, ®);
+ reg &= ~0xc0;
+ reg |= 0x40;
+ ret = pmic_reg_write(p, PFUZE3000_SW1ACONF, reg);
+ if (ret)
+ return ret;
+
+ /* set SW1B/VDD_SOC_IN step ramp up time from 16us to 4us/25mV */
+ pmic_reg_read(p, PFUZE3000_SW1BCONF, ®);
+ reg &= ~0xc0;
+ reg |= 0x40;
+ ret = pmic_reg_write(p, PFUZE3000_SW1BCONF, reg);
+ if (ret)
+ return ret;
+
+ /* set VDD_ARM_IN to 1.350V */
+ pmic_reg_read(p, PFUZE3000_SW1AVOLT, ®);
+ reg &= ~0x3f;
+ reg |= PFUZE3000_SW1AB_SETP(13500);
+ ret = pmic_reg_write(p, PFUZE3000_SW1AVOLT, reg);
+ if (ret)
+ return ret;
+
+ /* set VDD_SOC_IN to 1.350V */
+ pmic_reg_read(p, PFUZE3000_SW1BVOLT, ®);
+ reg &= ~0x3f;
+ reg |= PFUZE3000_SW1AB_SETP(13500);
+ ret = pmic_reg_write(p, PFUZE3000_SW1BVOLT, reg);
+ if (ret)
+ return ret;
+
+ /* set DDR_1_5V to 1.350V */
+ pmic_reg_read(p, PFUZE3000_SW3VOLT, ®);
+ reg &= ~0x0f;
+ reg |= PFUZE3000_SW3_SETP(13500);
+ ret = pmic_reg_write(p, PFUZE3000_SW3VOLT, reg);
+ if (ret)
+ return ret;
+
+ /* set VGEN2_1V5 to 1.5V */
+ pmic_reg_read(p, PFUZE3000_VLDO2CTL, ®);
+ reg &= ~0x0f;
+ reg |= PFUZE3000_VLDO_SETP(15000);
+ /* enable */
+ reg |= 0x10;
+ ret = pmic_reg_write(p, PFUZE3000_VLDO2CTL, reg);
+ if (ret)
+ return
[U-Boot] [PATCH 3/3] udoo_neo: Add Ethernet support
UDOO Neo boards has one FEC port connected to KSZ8091, add support for it.
Tested on a UDOO Neo Full with "dhcp zImage" command.
Signed-off-by: Breno Lima
---
board/udoo/neo/neo.c | 95 ++
configs/udoo_neo_defconfig | 2 +-
include/configs/udoo_neo.h | 17 -
3 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/board/udoo/neo/neo.c b/board/udoo/neo/neo.c
index ad7452c..688b522 100644
--- a/board/udoo/neo/neo.c
+++ b/board/udoo/neo/neo.c
@@ -10,6 +10,7 @@
*/
#include
+#include
#include
#include
#include
@@ -25,8 +26,11 @@
#include
#include
#include
+#include
+#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -50,6 +54,16 @@ enum {
PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
PAD_CTL_ODE)
+#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE | \
+ PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST)
+
+#define ENET_CLK_PAD_CTRL (PAD_CTL_SPEED_MED | \
+ PAD_CTL_DSE_120ohm | PAD_CTL_SRE_FAST)
+
+#define ENET_RX_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
+ PAD_CTL_SPEED_MED | PAD_CTL_SRE_FAST)
+
#define WDOG_PAD_CTRL (PAD_CTL_PUE | PAD_CTL_PKE | PAD_CTL_SPEED_MED | \
PAD_CTL_DSE_40ohm)
@@ -213,6 +227,27 @@ static iomux_v3_cfg_t const usdhc2_pads[] = {
MX6_PAD_SD1_CMD__GPIO6_IO_1 | MUX_PAD_CTRL(NO_PAD_CTRL),
};
+static iomux_v3_cfg_t const fec1_pads[] = {
+ MX6_PAD_ENET1_MDC__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET1_MDIO__ENET1_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII1_RX_CTL__ENET1_RX_EN | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+ MX6_PAD_RGMII1_RD0__ENET1_RX_DATA_0 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+ MX6_PAD_RGMII1_RD1__ENET1_RX_DATA_1 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+ MX6_PAD_RGMII1_TX_CTL__ENET1_TX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII1_RXC__ENET1_RX_ER | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+ MX6_PAD_RGMII1_TD0__ENET1_TX_DATA_0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_RGMII1_TD1__ENET1_TX_DATA_1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+ MX6_PAD_ENET2_TX_CLK__GPIO2_IO_9 | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
+ MX6_PAD_ENET1_CRS__GPIO2_IO_1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+};
+
+static iomux_v3_cfg_t const phy_control_pads[] = {
+ /* 25MHz Ethernet PHY Clock */
+ MX6_PAD_ENET2_RX_CLK__ENET2_REF_CLK_25M |
+ MUX_PAD_CTRL(ENET_CLK_PAD_CTRL),
+};
+
static iomux_v3_cfg_t const board_recognition_pads[] = {
/*Connected to R184*/
MX6_PAD_NAND_READY_B__GPIO4_IO_13 | BOARD_DETECT_PAD_CFG,
@@ -233,6 +268,66 @@ static void setup_iomux_uart(void)
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
}
+static int setup_fec(int fec_id)
+{
+ struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+ int reg;
+
+ imx_iomux_v3_setup_multiple_pads(phy_control_pads,
+ARRAY_SIZE(phy_control_pads));
+
+ /* Reset PHY */
+ gpio_direction_output(IMX_GPIO_NR(2, 1) , 0);
+ udelay(1);
+ gpio_set_value(IMX_GPIO_NR(2, 1), 1);
+ udelay(100);
+
+ reg = readl(&anatop->pll_enet);
+ reg |= BM_ANADIG_PLL_ENET_REF_25M_ENABLE;
+ writel(reg, &anatop->pll_enet);
+
+ return enable_fec_anatop_clock(fec_id, ENET_25MHZ);
+}
+
+int board_eth_init(bd_t *bis)
+{
+ uint32_t base = IMX_FEC_BASE;
+ struct mii_dev *bus = NULL;
+ struct phy_device *phydev = NULL;
+ int ret;
+
+ imx_iomux_v3_setup_multiple_pads(fec1_pads, ARRAY_SIZE(fec1_pads));
+
+ setup_fec(CONFIG_FEC_ENET_DEV);
+
+ bus = fec_get_miibus(base, CONFIG_FEC_ENET_DEV);
+ if (!bus)
+ return -EINVAL;
+
+ phydev = phy_find_by_mask(bus, (0x1 << CONFIG_FEC_MXC_PHYADDR),
+ PHY_INTERFACE_MODE_RMII);
+ if (!phydev) {
+ free(bus);
+ return -EINVAL;
+ }
+
+ ret = fec_probe(bis, CONFIG_FEC_ENET_DEV, base, bus, phydev);
+ if (ret) {
+ free(bus);
+ free(phydev);
+ return ret;
+ }
+ return 0;
+}
+
+int board_phy_config(struct phy_device *phydev)
+{
+ if (phydev->drv->config)
+ phydev->drv->config(phydev);
+
+ return 0;
+}
+
int board_init(void)
{
/* Address of boot parameters */
diff --git a/configs/udoo_neo_defconfig b/configs/udoo_neo_defconfig
index f88820c..5df4ef9 100644
--- a/configs/udoo_neo_defconfig
+++ b/configs/udoo_neo_defconfig
@@ -19,7 +19,7 @@ CONFIG_CMD_BOOTZ=y
CONFIG_CMD_MMC=y
CONFIG_CMD_GPIO=y
# CONFIG_CMD_SETEXPR is not set
-# CONFIG_CMD_DHCP=y
+CONFIG_CMD_DHCP=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_TIME=y
CONFIG_CMD_EXT2=y
diff --git a/include/configs/ud
[U-Boot] [PATCH 1/3] power: pmic: Add Voltage configuration macro
Add pfuze3000 voltage configuration macro for SW1AB, SW3 and VLDO1/2 according
to tables 53, 57 and 62 on PF3000 datasheet.
Signed-off-by: Breno Lima
---
Note: This patch series depends on my last series submission.
include/power/pfuze3000_pmic.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/power/pfuze3000_pmic.h b/include/power/pfuze3000_pmic.h
index e8b892b..7d66ba4 100644
--- a/include/power/pfuze3000_pmic.h
+++ b/include/power/pfuze3000_pmic.h
@@ -75,4 +75,9 @@ enum {
int power_pfuze3000_init(unsigned char bus);
+/* Voltage Configuration */
+#define PFUZE3000_SW1AB_SETP(x)((x - 7000) / 250)
+#define PFUZE3000_SW3_SETP(x) ((x - 9000) / 500)
+#define PFUZE3000_VLDO_SETP(x) ((x - 8000) / 500)
+
#endif
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/11] spi: cadence_qspi: Support specifying the sample edge used
Hi Jagan, On 06 December 2016 17:24 Jagan Teki wrote: > On Tue, Dec 6, 2016 at 6:00 PM, Phil Edworthy > wrote: > > Hi Jagan, Marek, > > > > On 06 December 2016 12:39 Marek Vasut wrote: > >> On 12/06/2016 11:25 AM, Phil Edworthy wrote: > >> > On 05 December 2016 13:31, Marek Vasut wrote: > >> >> On 12/05/2016 11:46 AM, Phil Edworthy wrote: > >> >>> On 05 December 2016 10:42, Jagan Teki wrote: > >> On Mon, Dec 5, 2016 at 11:31 AM, Phil Edworthy > >> wrote: > >> > On 05 December 2016 10:26, Jagan Teki wrote: > >> >> On Mon, Dec 5, 2016 at 11:09 AM, Phil Edworthy > >> >> wrote: > >> >>> On 02 December 2016 14:23, Jagan Teki wrote: > >> On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy > >> wrote: > >> > Introduce a new DT property to specify whether the QSPI > Controller > >> > samples the data on a rising edge. The default is falling edge. > >> > Some versions of the QSPI Controller do not implement this bit, > >> > in > >> > which case the property should be omitted. > > > > > >> Code look reasonable, but how Linux handling this with the same > dt > >> property, any idea? I couldn't find it either. > >> >>> The Linux driver does not yet have this property. Is there a > >> >>> policy to > add > >> >> new > >> >>> props to Linux first? > >> >> > >> >> If the same/equal code used in Linux better to have the same > property > >> >> instead of another name used in U-boot? > >> > Of course, but I cannot see this in Linux: > >> > https://git.kernel.org/cgit/linux/kernel/git/next/linux- > >> next.git/tree/Documentation/devicetree/bindings/spi/spi-cadence.txt > >> > >> Yeah, I saw this. Do you have any idea how Linux handling this sample > >> edge? > >> >>> The same way U-Boot currently handles it, i.e. it does nothing with > >> >>> this. > >> >> Intel/Altera > >> >>> (Chin Liang) said that they do not have this bit in their version of > >> >>> the > Cadence > >> >> QSPI > >> >>> Controller. > >> >>> > >> >>> We are using a later version that has had this bit added. > >> >> > >> >> You were looking at the wrong bindings: > >> >> https://git.kernel.org/cgit/linux/kernel/git/next/linux- > >> >> next.git/tree/Documentation/devicetree/bindings/mtd/cadence- > quadspi.txt > >> > Thanks for pointing that out! > >> > > >> >> but yes, Linux does not do support the data edge toggling. I think there > >> >> was another QSPI patch in Linux which tried adding such property, so > >> >> check linux-mtd for it. Generic one would be great. > >> > I had a search around, but couldn't find anything. > >> > >> Look for negative_edge here: > >> http://www.spinics.net/lists/devicetree/msg153582.html > >> > >> >> And no, there is no policy for pushing new props to linux first. New DT > >> >> props should ideally get approved via devicetree@vger though, but that's > >> >> about it. Also, while I tried backporting the Linux CQSPI driver to > >> >> U-Boot, but unfortunately, it turned out to be extremely difficult due > >> >> significant differences between the Linux and U-Boot SPI NOR framework. > >> > OK, thanks for the information. > > > > Since it will take a bit more time to get a generic prop for the sample > > edge to > > be ack'd by devicetree@vger, would it make sense to drop it from this > > series, > > so we can get the rest in? > > I can drop 10 and 11 from the series, is that OK? Yes please! Thanks Phil ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/13] imx6: icorem6: Add I2C support
On Tue, Dec 6, 2016 at 3:10 PM, Heiko Schocher wrote: > Hello Jagan, > > > Am 06.12.2016 um 00:01 schrieb Jagan Teki: >> >> From: Jagan Teki >> >> Add I2C support for Engicam i.CoreM6 qdl board. >> >> icorem6qdl> i2c bus >> Bus 0: i2c@021a >> Bus 1: i2c@021a4000 >> Bus 2: i2c@021a8000 >> icorem6qdl> i2c dev 2 >> Setting bus to 2 >> icorem6qdl> i2c speed 10 >> Setting bus speed to 10 Hz >> icorem6qdl> i2c probe >> Valid chip addresses: 2C >> icorem6qdl> i2c md 2C 0xff >> 00ff: 00 00 00 00 0f f0 01 64 ff ff 00 00 00 00 00 00...d >> >> Cc: Stefano Babic >> Cc: Heiko Schocher >> Cc: Matteo Lisi >> Cc: Michael Trimarchi >> Signed-off-by: Jagan Teki >> --- >> arch/arm/cpu/armv7/mx6/Kconfig | 1 + >> configs/imx6qdl_icore_mmc_defconfig | 3 ++- >> configs/imx6qdl_icore_nand_defconfig | 3 ++- >> 3 files changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/cpu/armv7/mx6/Kconfig >> b/arch/arm/cpu/armv7/mx6/Kconfig >> index f1ec75d..b686476 100644 >> --- a/arch/arm/cpu/armv7/mx6/Kconfig >> +++ b/arch/arm/cpu/armv7/mx6/Kconfig >> @@ -110,6 +110,7 @@ config TARGET_MX6Q_ICORE >> select DM >> select DM_ETH >> select DM_GPIO >> + select DM_I2C >> select DM_MMC >> select DM_THERMAL >> select SUPPORT_SPL >> diff --git a/configs/imx6qdl_icore_mmc_defconfig >> b/configs/imx6qdl_icore_mmc_defconfig >> index 6fa85de..5f09425 100644 >> --- a/configs/imx6qdl_icore_mmc_defconfig >> +++ b/configs/imx6qdl_icore_mmc_defconfig >> @@ -17,6 +17,7 @@ CONFIG_SYS_MAXARGS=32 >> # CONFIG_DM_MMC_OPS is not set >> CONFIG_CMD_BOOTZ=y >> CONFIG_CMD_GPIO=y >> +CONFIG_CMD_I2C=y >> CONFIG_CMD_MII=y >> CONFIG_CMD_PING=y >> CONFIG_CMD_MEMTEST=y >> @@ -33,6 +34,7 @@ CONFIG_MXC_UART=y >> CONFIG_IMX_THERMAL=y >> CONFIG_PINCTRL=y >> CONFIG_PINCTRL_IMX6=y >> +CONFIG_SYS_I2C_MXC=y >> CONFIG_VIDEO=y >> CONFIG_VIDEO_IPUV3=y >> CONFIG_SYS_CONSOLE_IS_IN_ENV=y >> @@ -40,7 +42,6 @@ CONFIG_SPL_LIBDISK_SUPPORT=y >> CONFIG_SPL_LIBCOMMON_SUPPORT=y >> CONFIG_SPL_LIBGENERIC_SUPPORT=y >> CONFIG_SPL_SERIAL_SUPPORT=y >> -CONFIG_SPL_I2C_SUPPORT=y > > > You remove here SPL I2C support ... is this intented ? Yes. 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 v3 11/11] spi: cadence_qspi: Support specifying the sample edge used
On Tue, Dec 6, 2016 at 6:00 PM, Phil Edworthy wrote: > Hi Jagan, Marek, > > On 06 December 2016 12:39 Marek Vasut wrote: >> On 12/06/2016 11:25 AM, Phil Edworthy wrote: >> > On 05 December 2016 13:31, Marek Vasut wrote: >> >> On 12/05/2016 11:46 AM, Phil Edworthy wrote: >> >>> On 05 December 2016 10:42, Jagan Teki wrote: >> On Mon, Dec 5, 2016 at 11:31 AM, Phil Edworthy >> wrote: >> > On 05 December 2016 10:26, Jagan Teki wrote: >> >> On Mon, Dec 5, 2016 at 11:09 AM, Phil Edworthy >> >> wrote: >> >>> On 02 December 2016 14:23, Jagan Teki wrote: >> On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy >> wrote: >> > Introduce a new DT property to specify whether the QSPI Controller >> > samples the data on a rising edge. The default is falling edge. >> > Some versions of the QSPI Controller do not implement this bit, in >> > which case the property should be omitted. > > >> Code look reasonable, but how Linux handling this with the same dt >> property, any idea? I couldn't find it either. >> >>> The Linux driver does not yet have this property. Is there a policy >> >>> to add >> >> new >> >>> props to Linux first? >> >> >> >> If the same/equal code used in Linux better to have the same property >> >> instead of another name used in U-boot? >> > Of course, but I cannot see this in Linux: >> > https://git.kernel.org/cgit/linux/kernel/git/next/linux- >> next.git/tree/Documentation/devicetree/bindings/spi/spi-cadence.txt >> >> Yeah, I saw this. Do you have any idea how Linux handling this sample >> edge? >> >>> The same way U-Boot currently handles it, i.e. it does nothing with this. >> >> Intel/Altera >> >>> (Chin Liang) said that they do not have this bit in their version of the >> >>> Cadence >> >> QSPI >> >>> Controller. >> >>> >> >>> We are using a later version that has had this bit added. >> >> >> >> You were looking at the wrong bindings: >> >> https://git.kernel.org/cgit/linux/kernel/git/next/linux- >> >> next.git/tree/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt >> > Thanks for pointing that out! >> > >> >> but yes, Linux does not do support the data edge toggling. I think there >> >> was another QSPI patch in Linux which tried adding such property, so >> >> check linux-mtd for it. Generic one would be great. >> > I had a search around, but couldn't find anything. >> >> Look for negative_edge here: >> http://www.spinics.net/lists/devicetree/msg153582.html >> >> >> And no, there is no policy for pushing new props to linux first. New DT >> >> props should ideally get approved via devicetree@vger though, but that's >> >> about it. Also, while I tried backporting the Linux CQSPI driver to >> >> U-Boot, but unfortunately, it turned out to be extremely difficult due >> >> significant differences between the Linux and U-Boot SPI NOR framework. >> > OK, thanks for the information. > > Since it will take a bit more time to get a generic prop for the sample edge > to > be ack'd by devicetree@vger, would it make sense to drop it from this series, > so we can get the rest in? I can drop 10 and 11 from the series, is that OK? 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 v3 11/11] spi: cadence_qspi: Support specifying the sample edge used
Hi Jagan, Marek, On 06 December 2016 12:39 Marek Vasut wrote: > On 12/06/2016 11:25 AM, Phil Edworthy wrote: > > On 05 December 2016 13:31, Marek Vasut wrote: > >> On 12/05/2016 11:46 AM, Phil Edworthy wrote: > >>> On 05 December 2016 10:42, Jagan Teki wrote: > On Mon, Dec 5, 2016 at 11:31 AM, Phil Edworthy > wrote: > > On 05 December 2016 10:26, Jagan Teki wrote: > >> On Mon, Dec 5, 2016 at 11:09 AM, Phil Edworthy > >> wrote: > >>> On 02 December 2016 14:23, Jagan Teki wrote: > On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy > wrote: > > Introduce a new DT property to specify whether the QSPI Controller > > samples the data on a rising edge. The default is falling edge. > > Some versions of the QSPI Controller do not implement this bit, in > > which case the property should be omitted. > Code look reasonable, but how Linux handling this with the same dt > property, any idea? I couldn't find it either. > >>> The Linux driver does not yet have this property. Is there a policy > >>> to add > >> new > >>> props to Linux first? > >> > >> If the same/equal code used in Linux better to have the same property > >> instead of another name used in U-boot? > > Of course, but I cannot see this in Linux: > > https://git.kernel.org/cgit/linux/kernel/git/next/linux- > next.git/tree/Documentation/devicetree/bindings/spi/spi-cadence.txt > > Yeah, I saw this. Do you have any idea how Linux handling this sample > edge? > >>> The same way U-Boot currently handles it, i.e. it does nothing with this. > >> Intel/Altera > >>> (Chin Liang) said that they do not have this bit in their version of the > >>> Cadence > >> QSPI > >>> Controller. > >>> > >>> We are using a later version that has had this bit added. > >> > >> You were looking at the wrong bindings: > >> https://git.kernel.org/cgit/linux/kernel/git/next/linux- > >> next.git/tree/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt > > Thanks for pointing that out! > > > >> but yes, Linux does not do support the data edge toggling. I think there > >> was another QSPI patch in Linux which tried adding such property, so > >> check linux-mtd for it. Generic one would be great. > > I had a search around, but couldn't find anything. > > Look for negative_edge here: > http://www.spinics.net/lists/devicetree/msg153582.html > > >> And no, there is no policy for pushing new props to linux first. New DT > >> props should ideally get approved via devicetree@vger though, but that's > >> about it. Also, while I tried backporting the Linux CQSPI driver to > >> U-Boot, but unfortunately, it turned out to be extremely difficult due > >> significant differences between the Linux and U-Boot SPI NOR framework. > > OK, thanks for the information. Since it will take a bit more time to get a generic prop for the sample edge to be ack'd by devicetree@vger, would it make sense to drop it from this series, so we can get the rest in? Thanks Phil ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4 02/16] dm: pci: return the real controller in pci_bus_to_hose()
On 12/05/2016 09:16 PM, Zhiqiang Hou wrote: > From: Minghuan Lian > > for the legacy PCI driver, the function pci_bus_to_hose() returns > the real PCIe controller. To keep consistency, this function is > changed to return the PCIe controller pointer of the root bus > instead of the current PCIe bus. > > Signed-off-by: Minghuan Lian > Signed-off-by: Hou Zhiqiang > --- > V4: > - No change > Zhiqiang, When you send a new set with some patches _unchanged_, you can add the review signature for them, so the reviewers don't have to send another one. This will help me to identify which one I should pay more attention. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: mkimage: Use fstat instead of stat to avoid malicious hacks
On Tue, Dec 06, 2016 at 05:17:01PM +0100, Michal Simek wrote: > The patch is fixing: > "tools: mkimage: Check if file is regular file" > (sha1: 56c7e8015509312240b1ee15f2ff74510939a45d) > which contains two issues reported by Coverity > Unchecked return value from stat and incorrect calling sequence where > attack can happen between calling stat and fopen. > Using pair in opposite order (fopen and fstat) is fixing this issue > because fstat is using the same file descriptor (FILE *). > > Also fixing issue with: > "tools: mkimage: Add support for initialization table for Zynq and > ZynqMP" (sha1: 3b6460809c2a28360029c1c48247648fac4455c9) > where file wasn't checked that it is regular file. > > Reported-by: Coverity (CID: 154711, 154712) > Signed-off-by: Michal Simek Thanks for the quick patch! Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: mkimage: Use fstat instead of stat to avoid malicious hacks
The patch is fixing:
"tools: mkimage: Check if file is regular file"
(sha1: 56c7e8015509312240b1ee15f2ff74510939a45d)
which contains two issues reported by Coverity
Unchecked return value from stat and incorrect calling sequence where
attack can happen between calling stat and fopen.
Using pair in opposite order (fopen and fstat) is fixing this issue
because fstat is using the same file descriptor (FILE *).
Also fixing issue with:
"tools: mkimage: Add support for initialization table for Zynq and
ZynqMP" (sha1: 3b6460809c2a28360029c1c48247648fac4455c9)
where file wasn't checked that it is regular file.
Reported-by: Coverity (CID: 154711, 154712)
Signed-off-by: Michal Simek
---
tools/zynqimage.c | 16 +---
tools/zynqmpimage.c | 14 +-
2 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/tools/zynqimage.c b/tools/zynqimage.c
index 43876e7a3024..b47132b02a60 100644
--- a/tools/zynqimage.c
+++ b/tools/zynqimage.c
@@ -225,16 +225,26 @@ static int zynqimage_check_image_types(uint8_t type)
static void zynqimage_parse_initparams(struct zynq_header *zynqhdr,
const char *filename)
{
- /* Expect a table of register-value pairs, e.g. "0x12345678 0x4321" */
- FILE *fp = fopen(filename, "r");
+ FILE *fp;
struct zynq_reginit reginit;
unsigned int reg_count = 0;
- int r;
+ int r, err;
+ struct stat path_stat;
+ /* Expect a table of register-value pairs, e.g. "0x12345678 0x4321" */
+ fp = fopen(filename, "r");
if (!fp) {
fprintf(stderr, "Cannot open initparams file: %s\n", filename);
exit(1);
}
+
+ err = fstat(fileno(fp), &path_stat);
+ if (err)
+ return;
+
+ if (!S_ISREG(path_stat.st_mode))
+ return;
+
do {
r = fscanf(fp, "%x %x", ®init.address, ®init.data);
if (r == 2) {
diff --git a/tools/zynqmpimage.c b/tools/zynqmpimage.c
index 202faea07295..60d8ed23b4a1 100644
--- a/tools/zynqmpimage.c
+++ b/tools/zynqmpimage.c
@@ -240,19 +240,23 @@ static void zynqmpimage_parse_initparams(struct
zynqmp_header *zynqhdr,
FILE *fp;
struct zynqmp_reginit reginit;
unsigned int reg_count = 0;
- int r;
+ int r, err;
struct stat path_stat;
- stat(filename, &path_stat);
- if (!S_ISREG(path_stat.st_mode))
- return;
-
/* Expect a table of register-value pairs, e.g. "0x12345678 0x4321" */
fp = fopen(filename, "r");
if (!fp) {
fprintf(stderr, "Cannot open initparams file: %s\n", filename);
exit(1);
}
+
+ err = fstat(fileno(fp), &path_stat);
+ if (err)
+ return;
+
+ if (!S_ISREG(path_stat.st_mode))
+ return;
+
do {
r = fscanf(fp, "%x %x", ®init.address, ®init.data);
if (r == 2) {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] arm: am57xx: cl-som-am57x: add initial board support
Hi Tom, Sending again - reply all On 12/05/2016 05:28 PM, Tom Rini wrote: On Mon, Dec 05, 2016 at 10:27:55AM +0200, Uri Mashiach wrote: From: Dmitry Lifshitz Features supported : * Serial console * SPI Flash * MMC/SD Card * eMMC storage * SATA * PCA9555 - GPIO expander over I2C5 bus * USB Use spl alternate boot device feature to define fallback to the main boot device as it is defined by hardware. Signed-off-by: Dmitry Lifshitz [uri.mashi...@compulab.co.il: Adjust to v2016.11] Signed-off-by: Uri Mashiach Acked-by: Igor Grinberg [snip] +++ b/configs/cl-som-am57x_defconfig @@ -0,0 +1,41 @@ +CONFIG_ARM=y +CONFIG_OMAP54XX=y +# CONFIG_SPL_NAND_SUPPORT is not set +CONFIG_TARGET_CL_SOM_AM57X=y +CONFIG_VERSION_VARIABLE=y +CONFIG_SPL=y +CONFIG_HUSH_PARSER=y +CONFIG_CMD_BOOTZ=y Are you intentionally not enabling the generic distro framework? Will be tested and included in the next CL-SOM-AM57x patch set. [snip] +++ b/include/configs/cl-som-am57x.h [snip] +/* SPI SPL defines */ +#undef CONFIG_SPL_OS_BOOT This isn't needed, it's moved to Kconfig and defaults to off. Will be updated in v2 Thanks! -- Thanks, Uri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: enable H3 EMAC for the nanopi neo
On Mon, Dec 05, 2016 at 07:47:21PM +0100, Jelle van der Waa wrote: > The nanopi already had the CONFIG_SUN8I_EMAC=y enabled in it's defconfig > file, but was missing the &emac the device tree entry. > > Signed-off-by: Jelle van der Waa Acked-by: Maxime Ripard Thanks, 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 0/3] SPL: move CONFIG_SPL_*_LOAD to Kconfig
On Tue, Dec 06, 2016 at 05:57:57PM +0200, Igor Grinberg wrote:
> Hi Tom,
>
> On 12/06/16 16:32, Tom Rini wrote:
> > On Tue, Dec 06, 2016 at 02:48:27PM +0100, Fabien Parent wrote:
> >
> >> Moving to CONFIG_SPL_*_LOAD options to Kconfig offers several advantage:
> >> * simpler config headers
> >> * on some boards we can easily switch to another boot media without
> >> needing
> >>to modify the config headers.
> >>
> >> This series fixes an issue in davinci where a wrong option was used in
> >> place
> >> of a CONFIG_SPL_*_LOAD option, then move the options to Kconfig options,
> >> and
> >> finally start using these Kconfig options for the OMAPL138-LCDK board.
> >>
> >> Fabien Parent (3):
> >> davinci: spl: use correct macro to select boot device
> >> SPL: create Kconfig options for CONFIG_SPL_*_LOAD
> >> davinci: omapl138_lcdk: use new CONFIG_SPL_*_LOAD Kconfig options
> >>
> >> arch/arm/mach-davinci/spl.c | 2 +-
> >> common/spl/Kconfig | 25 +
> >> configs/omapl138_lcdk_defconfig | 1 +
> >> include/configs/omapl138_lcdk.h | 2 --
> >> scripts/config_whitelist.txt| 3 ---
> >> 5 files changed, 27 insertions(+), 6 deletions(-)
> >
> > So, I think this shows that some of the SPL framework needs to be
> > revisited for davinci. First, lets make it clear what
> > CONFIG_SPL_{SPI,NAND,MMC}_LOAD is doing.
> >
> > CONFIG_SPL_MMC_LOAD is used to flag that on davinci we're loading U-Boot
> > from MMC. It's not set / used today but I assume it was working when I
> > introduced all of this.
> >
> > CONFIG_SPL_NAND_LOAD is used for two things. First, it is used to flag
> > that on davinci we're loading U-Boot from NAND. Second, it is used to
> > enable the non-SPL_FRAMEWORK NAND driver
> > (drivers/mtd/nand/nand_spl_load.c). This driver is not used on davinci.
> >
> > CONFIG_SPL_SPI_LOAD is used for two things. First, it is used to flag
> > that on davinci we're loading U-Boot from SPI flash. Second, it used
> > globally to enable common/spl/spl_spi.c.
> >
> > NAND boot is done here via CONFIG_SPL_NAND_SIMPLE which is the regular
> > SPL framework based NAND driver (drivers/mtd/nand/nand_spl_simple.c).
> > This also means that the patch to update CONFIG_SYS_NAND_U_BOOT_SIZE was
> > not needed since we don't use that driver.
> >
> > Now, I think that in retrospect
> > arch/arm/mach-davinci/spl.c::spl_boot_device could be re-worked to key
> > off of CONFIG_SPL_NAND_SIMPLE / CONFIG_SPL_SPI_SUPPORT / SPL_MMC_SUPPORT.
> >
> > And a good but possibly complex series would be to consolidate the usage
> > of SPL_SPI_SUPPORT, SPL_SPI_FLASH_SUPPORT and SPL_SPI_LOAD just in to
> > SPL_SPI_SUPPORT. I'll probably try and do this myself as there's a ton
> > of build testing and size checking to make sure nothing odd breaks here
> > to do.
>
> Just a thought...
> Are you sure you want to combine all three (spi, spi flash, and spi load)
> under one define?
> Won't be there any case for parsing some spi device (say eeprom) in the SPL,
> but no spi flash to load U-Boot from?
> It might be sensible to keep the "spi flash" and the "spi load" together, but
> I think it might be more beneficial to keep the spi bus support apart.
Ah, good point. I don't know if we have that case today, but that would
be one of the gotchas I'd be size-checking for. And another place where
the 'imply' keyword Masahiro pointed out earlier would be helpful for
too. 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 0/3] SPL: move CONFIG_SPL_*_LOAD to Kconfig
Hi Tom,
On 12/06/16 16:32, Tom Rini wrote:
> On Tue, Dec 06, 2016 at 02:48:27PM +0100, Fabien Parent wrote:
>
>> Moving to CONFIG_SPL_*_LOAD options to Kconfig offers several advantage:
>> * simpler config headers
>> * on some boards we can easily switch to another boot media without needing
>>to modify the config headers.
>>
>> This series fixes an issue in davinci where a wrong option was used in place
>> of a CONFIG_SPL_*_LOAD option, then move the options to Kconfig options, and
>> finally start using these Kconfig options for the OMAPL138-LCDK board.
>>
>> Fabien Parent (3):
>> davinci: spl: use correct macro to select boot device
>> SPL: create Kconfig options for CONFIG_SPL_*_LOAD
>> davinci: omapl138_lcdk: use new CONFIG_SPL_*_LOAD Kconfig options
>>
>> arch/arm/mach-davinci/spl.c | 2 +-
>> common/spl/Kconfig | 25 +
>> configs/omapl138_lcdk_defconfig | 1 +
>> include/configs/omapl138_lcdk.h | 2 --
>> scripts/config_whitelist.txt| 3 ---
>> 5 files changed, 27 insertions(+), 6 deletions(-)
>
> So, I think this shows that some of the SPL framework needs to be
> revisited for davinci. First, lets make it clear what
> CONFIG_SPL_{SPI,NAND,MMC}_LOAD is doing.
>
> CONFIG_SPL_MMC_LOAD is used to flag that on davinci we're loading U-Boot
> from MMC. It's not set / used today but I assume it was working when I
> introduced all of this.
>
> CONFIG_SPL_NAND_LOAD is used for two things. First, it is used to flag
> that on davinci we're loading U-Boot from NAND. Second, it is used to
> enable the non-SPL_FRAMEWORK NAND driver
> (drivers/mtd/nand/nand_spl_load.c). This driver is not used on davinci.
>
> CONFIG_SPL_SPI_LOAD is used for two things. First, it is used to flag
> that on davinci we're loading U-Boot from SPI flash. Second, it used
> globally to enable common/spl/spl_spi.c.
>
> NAND boot is done here via CONFIG_SPL_NAND_SIMPLE which is the regular
> SPL framework based NAND driver (drivers/mtd/nand/nand_spl_simple.c).
> This also means that the patch to update CONFIG_SYS_NAND_U_BOOT_SIZE was
> not needed since we don't use that driver.
>
> Now, I think that in retrospect
> arch/arm/mach-davinci/spl.c::spl_boot_device could be re-worked to key
> off of CONFIG_SPL_NAND_SIMPLE / CONFIG_SPL_SPI_SUPPORT / SPL_MMC_SUPPORT.
>
> And a good but possibly complex series would be to consolidate the usage
> of SPL_SPI_SUPPORT, SPL_SPI_FLASH_SUPPORT and SPL_SPI_LOAD just in to
> SPL_SPI_SUPPORT. I'll probably try and do this myself as there's a ton
> of build testing and size checking to make sure nothing odd breaks here
> to do.
Just a thought...
Are you sure you want to combine all three (spi, spi flash, and spi load)
under one define?
Won't be there any case for parsing some spi device (say eeprom) in the SPL,
but no spi flash to load U-Boot from?
It might be sensible to keep the "spi flash" and the "spi load" together, but
I think it might be more beneficial to keep the spi bus support apart.
--
Regards,
Igor.
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] davinci: omapl138_lcdk: boot from zImage
On Tue, Dec 06, 2016 at 03:45:09PM +0100, Fabien Parent wrote: > Stop booting legacy uImage and now boot zImage. > > Signed-off-by: Fabien Parent Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/13] i2c: Kconfig: Add SYS_I2C_MXC entry
On Tue, Dec 6, 2016 at 3:06 PM, Heiko Schocher wrote: > Hello Jagan, > > > Am 06.12.2016 um 00:00 schrieb Jagan Teki: >> >> From: Jagan Teki >> >> Added kconfig for SYS_I2C_MXC driver. >> >> Cc: Stefano Babic >> Cc: Heiko Schocher >> Cc: Matteo Lisi >> Cc: Michael Trimarchi >> Signed-off-by: Jagan Teki >> --- >> drivers/i2c/Kconfig | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig >> index 1537b67..051f911 100644 >> --- a/drivers/i2c/Kconfig >> +++ b/drivers/i2c/Kconfig >> @@ -109,6 +109,14 @@ config SYS_I2C_INTEL >> the I2C API meaning that any I2C operations will immediately >> fail >> for now. >> >> +config SYS_I2C_MXC >> + bool "NXP i.MX I2C driver" >> + depends on MX6 >> + help >> + Add support for the NXP i.MX I2C driver. This supports upto for >> bus >> + channels and operating on standard mode upto 100 kbits/s and >> fast >> + mode upto 400 kbits/s. >> + >> config SYS_I2C_ROCKCHIP >> bool "Rockchip I2C driver" >> depends on DM_I2C >> > > I miss here junks, which move this symbol from the board config file > into their defconfig file ... Can you add this please? Yes I will add them in separate patch. 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 v3 10/13] i2c: Kconfig: Add SYS_I2C_MXC entry
On Tue, Dec 6, 2016 at 3:47 PM, Fabio Estevam wrote: > On Mon, Dec 5, 2016 at 9:00 PM, Jagan Teki wrote: > >> +config SYS_I2C_MXC >> + bool "NXP i.MX I2C driver" >> + depends on MX6 > > This driver is used among several i.MX SoC, so it would be better not > to restrict it to MX6 only. True, but the icorem6 is MX6 only so, the rest will ||ed while moving respective CONFIG_ to defconfig files 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] [RFC PATCH] ARM: zynq: Replace dram_init* functions with board_init_f safe ones
Hi Nathan,
On 4.12.2016 10:33, Nathan Rossi wrote:
> The dram_init* functions for the zynq board are not safe for use from
> the board_init_f stage due to its use of the 'tmp' static variable.
>
> This incorrect use of a static variable was causing rare issues where
> the dram_init function would overwrite some parts the __rel_dyn section
> which caused obscure failures.
>
> Using the zynq_zybo configuration, U-Boot would generate the following
> error during image load. This was caused due to dram_init overwriting
> the relocations for the "image" variable within the do_bootm function.
> Out of coincidence the un-initialized memory has a compression type
> which is the same as the value for the relocation type R_ARM_RELATIVE.
>
>Uncompressing Invalid Image ... Unimplemented compression type 23
First of all I didn't see any issue like this before but it is serious
issue.
>
> It should be noted that this is just one way the issue could surface,
> other cases my not be observed in normal boot flow.
>
> This change removes the existing code and copies the implementation of
> the dram_init and dram_init_banksize from the
> arch/arm/mach-uniphier/dram_init.c source. This version of these
> functions does not use static variables and behaves the same (reading
> banks from fdt, and using the first bank as the ram_size).
>
> Signed-off-by: Nathan Rossi
> Fixes: 758f29d0f8 ("ARM: zynq: Support systems with more memory banks")
> Cc: Michal Simek
> ---
> I am sending this as an RFC first to query whether it would make sense
> to have the setup of memory info based on FDT information as a common
> function that could be re-used or maybe always used (if OF enabled and
> SDRAM_SIZE not used) from board_init_f. And in that regard get some
> feedback on the best way to implement such.
>
> This change would also need to be applied to the zynqmp dram_init*
> functions.
Yes - the same stuff is used by zynqmp. TBH I would prefer to get this
code to generic location and use it.
It will be necessary to test zynq and zynqmp code and I am happy if this
is working for all valid configurations.
address cells, size-cells
1 1
2 1
1 2
2 2
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/13] i2c: Kconfig: Add SYS_I2C_MXC entry
On Mon, Dec 5, 2016 at 9:00 PM, Jagan Teki wrote: > +config SYS_I2C_MXC > + bool "NXP i.MX I2C driver" > + depends on MX6 This driver is used among several i.MX SoC, so it would be better not to restrict it to MX6 only. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] davinci: omapl138_lcdk: boot from zImage
Stop booting legacy uImage and now boot zImage.
Signed-off-by: Fabien Parent
---
v1 .. v2
* Used __stringify(CONFIG_BOOTFILE) to avoid code duplication
---
configs/omapl138_lcdk_defconfig | 1 +
include/configs/omapl138_lcdk.h | 9 +
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
index 52681c92d0..d030ffafc3 100644
--- a/configs/omapl138_lcdk_defconfig
+++ b/configs/omapl138_lcdk_defconfig
@@ -13,6 +13,7 @@ CONFIG_SPL=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
CONFIG_HUSH_PARSER=y
CONFIG_SYS_PROMPT="U-Boot > "
+CONFIG_CMD_BOOTZ=y
# CONFIG_CMD_IMLS is not set
CONFIG_CMD_ASKENV=y
# CONFIG_CMD_FLASH is not set
diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h
index 7c2f4141c9..ea28db2f59 100644
--- a/include/configs/omapl138_lcdk.h
+++ b/include/configs/omapl138_lcdk.h
@@ -247,7 +247,7 @@
*/
#define CONFIG_MISC_INIT_R
#define CONFIG_BOARD_EARLY_INIT_F
-#define CONFIG_BOOTFILE"uImage" /* Boot file name */
+#define CONFIG_BOOTFILE"zImage" /* Boot file name */
#define CONFIG_SYS_CBSIZE 1024 /* Console I/O Buffer Size */
#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16)
#define CONFIG_SYS_MAXARGS 16 /* max number of command args */
@@ -276,19 +276,20 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"fdtaddr=0xc060\0" \
"fdtfile=da850-lcdk.dtb\0" \
- "fdtboot=bootm 0xc070 - ${fdtaddr};\0" \
+ "fdtboot=bootz 0xc070 - ${fdtaddr};\0" \
"mmcboot=" \
"if fatload mmc 0 0xc060 boot.scr; then " \
"source 0xc060; " \
"else " \
- "fatload mmc 0 0xc070 uImage; " \
+ "fatload mmc 0 0xc070 " \
+ __stringify(CONFIG_BOOTFILE) "; " \
"fatload mmc 0 ${fdtaddr} ${fdtfile}; " \
"run fdtboot; " \
"fi;\0" \
"spiboot=" \
"sf probe 0; " \
"sf read 0xc070 0x8 0x22; " \
- "bootm 0xc070;\0"
+ "bootz 0xc070;\0"
/*
* U-Boot commands
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] SPL: move CONFIG_SPL_*_LOAD to Kconfig
On Tue, Dec 06, 2016 at 02:48:27PM +0100, Fabien Parent wrote:
> Moving to CONFIG_SPL_*_LOAD options to Kconfig offers several advantage:
> * simpler config headers
> * on some boards we can easily switch to another boot media without needing
>to modify the config headers.
>
> This series fixes an issue in davinci where a wrong option was used in place
> of a CONFIG_SPL_*_LOAD option, then move the options to Kconfig options, and
> finally start using these Kconfig options for the OMAPL138-LCDK board.
>
> Fabien Parent (3):
> davinci: spl: use correct macro to select boot device
> SPL: create Kconfig options for CONFIG_SPL_*_LOAD
> davinci: omapl138_lcdk: use new CONFIG_SPL_*_LOAD Kconfig options
>
> arch/arm/mach-davinci/spl.c | 2 +-
> common/spl/Kconfig | 25 +
> configs/omapl138_lcdk_defconfig | 1 +
> include/configs/omapl138_lcdk.h | 2 --
> scripts/config_whitelist.txt| 3 ---
> 5 files changed, 27 insertions(+), 6 deletions(-)
So, I think this shows that some of the SPL framework needs to be
revisited for davinci. First, lets make it clear what
CONFIG_SPL_{SPI,NAND,MMC}_LOAD is doing.
CONFIG_SPL_MMC_LOAD is used to flag that on davinci we're loading U-Boot
from MMC. It's not set / used today but I assume it was working when I
introduced all of this.
CONFIG_SPL_NAND_LOAD is used for two things. First, it is used to flag
that on davinci we're loading U-Boot from NAND. Second, it is used to
enable the non-SPL_FRAMEWORK NAND driver
(drivers/mtd/nand/nand_spl_load.c). This driver is not used on davinci.
CONFIG_SPL_SPI_LOAD is used for two things. First, it is used to flag
that on davinci we're loading U-Boot from SPI flash. Second, it used
globally to enable common/spl/spl_spi.c.
NAND boot is done here via CONFIG_SPL_NAND_SIMPLE which is the regular
SPL framework based NAND driver (drivers/mtd/nand/nand_spl_simple.c).
This also means that the patch to update CONFIG_SYS_NAND_U_BOOT_SIZE was
not needed since we don't use that driver.
Now, I think that in retrospect
arch/arm/mach-davinci/spl.c::spl_boot_device could be re-worked to key
off of CONFIG_SPL_NAND_SIMPLE / CONFIG_SPL_SPI_SUPPORT / SPL_MMC_SUPPORT.
And a good but possibly complex series would be to consolidate the usage
of SPL_SPI_SUPPORT, SPL_SPI_FLASH_SUPPORT and SPL_SPI_LOAD just in to
SPL_SPI_SUPPORT. I'll probably try and do this myself as there's a ton
of build testing and size checking to make sure nothing odd breaks here
to do.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/23] sunxi: A64: use H3 DRAM initialization code for A64
Hi,
On 06/12/16 11:20, Maxime Ripard wrote:
> On Mon, Dec 05, 2016 at 01:52:22AM +, Andre Przywara wrote:
>> From: Jens Kuske
>>
>> The A64 DRAM controller is very similar to the H3 one,
>> so the code can be reused with some small changes.
>> [Andre: fixed up typo, merged in fixes from Jens]
>>
>> Signed-off-by: Jens Kuske
>> Signed-off-by: Andre Przywara
>> ---
>> arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 1 +
>> arch/arm/include/asm/arch-sunxi/dram.h | 2 +-
>> arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h | 10 +-
>> arch/arm/mach-sunxi/Makefile| 1 +
>> arch/arm/mach-sunxi/clock_sun6i.c | 2 +-
>> arch/arm/mach-sunxi/dram_sun8i_h3.c | 139
>> +++-
>> 6 files changed, 123 insertions(+), 32 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>> index be9fcfd..3f87672 100644
>> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>> @@ -322,6 +322,7 @@ struct sunxi_ccm_reg {
>> #define CCM_DRAMCLK_CFG_DIV0_MASK (0xf << 8)
>> #define CCM_DRAMCLK_CFG_SRC_PLL5(0x0 << 20)
>> #define CCM_DRAMCLK_CFG_SRC_PLL6x2 (0x1 << 20)
>> +#define CCM_DRAMCLK_CFG_SRC_PLL11 (0x1 << 20) /* A64 only */
>> #define CCM_DRAMCLK_CFG_SRC_MASK(0x3 << 20)
>> #define CCM_DRAMCLK_CFG_UPD (0x1 << 16)
>> #define CCM_DRAMCLK_CFG_RST (0x1 << 31)
>> diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
>> b/arch/arm/include/asm/arch-sunxi/dram.h
>> index e0be744..53e6d47 100644
>> --- a/arch/arm/include/asm/arch-sunxi/dram.h
>> +++ b/arch/arm/include/asm/arch-sunxi/dram.h
>> @@ -24,7 +24,7 @@
>> #include
>> #elif defined(CONFIG_MACH_SUN8I_A83T)
>> #include
>> -#elif defined(CONFIG_MACH_SUN8I_H3)
>> +#elif defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
>> #include
>> #elif defined(CONFIG_MACH_SUN9I)
>> #include
>> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
>> b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
>> index 867fd12..b0e5d93 100644
>> --- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
>> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
>> @@ -15,7 +15,8 @@
>>
>> struct sunxi_mctl_com_reg {
>> u32 cr; /* 0x00 control register */
>> -u8 res0[0xc]; /* 0x04 */
>> +u8 res0[0x8]; /* 0x04 */
>> +u32 tmr;/* 0x0c (A64 only) */
>
> #ifdef?
What would that change aside from making it hard to read?
This is a structure definition, so it doesn't generate any code on its
own. And we only access that field from the A64, so it keeps its
reserved nature for the H3.
>> u32 mcr[16][2]; /* 0x10 */
>> u32 bwcr; /* 0x90 bandwidth control register */
>> u32 maer; /* 0x94 master enable register */
>> @@ -32,7 +33,9 @@ struct sunxi_mctl_com_reg {
>> u32 swoffr; /* 0xc4 */
>> u8 res2[0x8]; /* 0xc8 */
>> u32 cccr; /* 0xd0 */
>> -u8 res3[0x72c]; /* 0xd4 */
>> +u8 res3[0x54]; /* 0xd4 */
>> +u32 mdfs_bwlr[3]; /* 0x128 (A64 only) */
>> +u8 res4[0x6cc]; /* 0x134 */
>
> Ditto.
>
>> u32 protect;/* 0x800 */
>> };
>>
>> @@ -81,7 +84,8 @@ struct sunxi_mctl_ctl_reg {
>> u32 rfshtmg;/* 0x90 refresh timing */
>> u32 rfshctl1; /* 0x94 */
>> u32 pwrtmg; /* 0x98 */
>> -u8 res3[0x20]; /* 0x9c */
>> +u8 res3[0x1c]; /* 0x9c */
>> +u32 vtfcr; /* 0xb8 (A64 only) */
>
> Ditto
>
>> u32 dqsgmr; /* 0xbc */
>> u32 dtcr; /* 0xc0 */
>> u32 dtar[4];/* 0xc4 */
>> diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
>> index e73114e..7daba11 100644
>> --- a/arch/arm/mach-sunxi/Makefile
>> +++ b/arch/arm/mach-sunxi/Makefile
>> @@ -50,4 +50,5 @@ obj-$(CONFIG_MACH_SUN8I_A33) += dram_sun8i_a33.o
>> obj-$(CONFIG_MACH_SUN8I_A83T) += dram_sun8i_a83t.o
>> obj-$(CONFIG_MACH_SUN8I_H3) += dram_sun8i_h3.o
>> obj-$(CONFIG_MACH_SUN9I)+= dram_sun9i.o
>> +obj-$(CONFIG_MACH_SUN50I) += dram_sun8i_h3.o
>> endif
>> diff --git a/arch/arm/mach-sunxi/clock_sun6i.c
>> b/arch/arm/mach-sunxi/clock_sun6i.c
>> index 80cfc0b..99f515d 100644
>> --- a/arch/arm/mach-sunxi/clock_sun6i.c
>> +++ b/arch/arm/mach-sunxi/clock_sun6i.c
>> @@ -217,7 +217,7 @@ done:
>> }
>> #endif
>>
>> -#ifdef CONFIG_MACH_SUN8I_A33
>> +#if defined(CONFIG_MACH_SUN8I_A33) || defined(CONFIG_MACH_SUN50I)
>> void clock_set_pll11(unsigned int clk, bool sigma_delta_enable)
>> {
>> struct sunxi_ccm_reg * const ccm =
>> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> index 1647d76..2dc2071 100644
>> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> +++ b/arch/ar
Re: [U-Boot] [PATCH v3 13/13] imx6: icorem6: Add I2C support
Hello Jagan, Am 06.12.2016 um 00:01 schrieb Jagan Teki: From: Jagan Teki Add I2C support for Engicam i.CoreM6 qdl board. icorem6qdl> i2c bus Bus 0: i2c@021a Bus 1: i2c@021a4000 Bus 2: i2c@021a8000 icorem6qdl> i2c dev 2 Setting bus to 2 icorem6qdl> i2c speed 10 Setting bus speed to 10 Hz icorem6qdl> i2c probe Valid chip addresses: 2C icorem6qdl> i2c md 2C 0xff 00ff: 00 00 00 00 0f f0 01 64 ff ff 00 00 00 00 00 00...d Cc: Stefano Babic Cc: Heiko Schocher Cc: Matteo Lisi Cc: Michael Trimarchi Signed-off-by: Jagan Teki --- arch/arm/cpu/armv7/mx6/Kconfig | 1 + configs/imx6qdl_icore_mmc_defconfig | 3 ++- configs/imx6qdl_icore_nand_defconfig | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig index f1ec75d..b686476 100644 --- a/arch/arm/cpu/armv7/mx6/Kconfig +++ b/arch/arm/cpu/armv7/mx6/Kconfig @@ -110,6 +110,7 @@ config TARGET_MX6Q_ICORE select DM select DM_ETH select DM_GPIO + select DM_I2C select DM_MMC select DM_THERMAL select SUPPORT_SPL diff --git a/configs/imx6qdl_icore_mmc_defconfig b/configs/imx6qdl_icore_mmc_defconfig index 6fa85de..5f09425 100644 --- a/configs/imx6qdl_icore_mmc_defconfig +++ b/configs/imx6qdl_icore_mmc_defconfig @@ -17,6 +17,7 @@ CONFIG_SYS_MAXARGS=32 # CONFIG_DM_MMC_OPS is not set CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y CONFIG_CMD_MII=y CONFIG_CMD_PING=y CONFIG_CMD_MEMTEST=y @@ -33,6 +34,7 @@ CONFIG_MXC_UART=y CONFIG_IMX_THERMAL=y CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX6=y +CONFIG_SYS_I2C_MXC=y CONFIG_VIDEO=y CONFIG_VIDEO_IPUV3=y CONFIG_SYS_CONSOLE_IS_IN_ENV=y @@ -40,7 +42,6 @@ CONFIG_SPL_LIBDISK_SUPPORT=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y -CONFIG_SPL_I2C_SUPPORT=y You remove here SPL I2C support ... is this intented ? If so, you can add my: Acked-by: Heiko Schocher bye, Heiko CONFIG_SPL_GPIO_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_SPL_EXT_SUPPORT=y diff --git a/configs/imx6qdl_icore_nand_defconfig b/configs/imx6qdl_icore_nand_defconfig index b32eea9..af3a9f8 100644 --- a/configs/imx6qdl_icore_nand_defconfig +++ b/configs/imx6qdl_icore_nand_defconfig @@ -15,6 +15,7 @@ CONFIG_SYS_MAXARGS=32 # CONFIG_CMD_IMLS is not set CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y CONFIG_CMD_MII=y CONFIG_CMD_PING=y CONFIG_CMD_MEMTEST=y @@ -29,13 +30,13 @@ CONFIG_IMX_THERMAL=y # CONFIG_DM_MMC_OPS is not set CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX6=y +CONFIG_SYS_I2C_MXC=y CONFIG_VIDEO=y CONFIG_VIDEO_IPUV3=y CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y -CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_GPIO_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_SPL_DMA_SUPPORT=y -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/13] i2c: mxc: Make 'no gpio pinctrl state' print as debug
Hello Jagan,
Am 06.12.2016 um 00:00 schrieb Jagan Teki:
From: Jagan Teki
Some I2C bus devicetree nodes, doesn't require to have
gpio pinctrl so replace the dev_info to debug so the
print never comes on the console and for bus that uses
gpio pinctrl anyway have dev_err.
Before:
--
U-Boot> i2c dev 1
Setting bus to 1
i2c bus 1 at 0x21a4000, no gpio pinctrl state.
After:
--
U-Boot> i2c dev 1
Setting bus to 1
Cc: Simon Glass
Cc: Heiko Schocher
Cc: Peng Fan
Cc: Michael Trimarchi
Signed-off-by: Jagan Teki
---
drivers/i2c/mxc_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Heiko Schocher
bye,
Heiko
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 03a5ce9..94d9027 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -775,7 +775,7 @@ static int mxc_i2c_probe(struct udevice *bus)
*/
ret = fdt_stringlist_search(fdt, node, "pinctrl-names", "gpio");
if (ret < 0) {
- dev_info(dev, "i2c bus %d at 0x%2lx, no gpio pinctrl state.\n",
bus->seq, i2c_bus->base);
+ debug("i2c bus %d at 0x%2lx, no gpio pinctrl state.\n", bus->seq,
i2c_bus->base);
} else {
ret = gpio_request_by_name_nodev(fdt, node, "scl-gpios",
0, &i2c_bus->scl_gpio,
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/13] i2c: mxc: Print hex instead of decimal for bus address
Hello Jagan,
Am 06.12.2016 um 00:00 schrieb Jagan Teki:
From: Jagan Teki
Better to print the hex value for bus address instead of
decimal, for more readbility on bus addressing.
Before:
--
U-Boot> i2c dev 1
Setting bus to 1
i2c bus 1 at 35274752, no gpio pinctrl state.
After:
--
U-Boot> i2c dev 1
Setting bus to 1
i2c bus 1 at 0x21a4000, no gpio pinctrl state.
Cc: Simon Glass
Cc: Heiko Schocher
Cc: Peng Fan
Cc: Michael Trimarchi
Signed-off-by: Jagan Teki
---
drivers/i2c/mxc_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Heiko Schocher
bye,
Heiko
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index 6247d33..03a5ce9 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -775,7 +775,7 @@ static int mxc_i2c_probe(struct udevice *bus)
*/
ret = fdt_stringlist_search(fdt, node, "pinctrl-names", "gpio");
if (ret < 0) {
- dev_info(dev, "i2c bus %d at %lu, no gpio pinctrl state.\n",
bus->seq, i2c_bus->base);
+ dev_info(dev, "i2c bus %d at 0x%2lx, no gpio pinctrl state.\n",
bus->seq, i2c_bus->base);
} else {
ret = gpio_request_by_name_nodev(fdt, node, "scl-gpios",
0, &i2c_bus->scl_gpio,
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/13] i2c: Kconfig: Add SYS_I2C_MXC entry
Hello Jagan, Am 06.12.2016 um 00:00 schrieb Jagan Teki: From: Jagan Teki Added kconfig for SYS_I2C_MXC driver. Cc: Stefano Babic Cc: Heiko Schocher Cc: Matteo Lisi Cc: Michael Trimarchi Signed-off-by: Jagan Teki --- drivers/i2c/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 1537b67..051f911 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -109,6 +109,14 @@ config SYS_I2C_INTEL the I2C API meaning that any I2C operations will immediately fail for now. +config SYS_I2C_MXC + bool "NXP i.MX I2C driver" + depends on MX6 + help + Add support for the NXP i.MX I2C driver. This supports upto for bus + channels and operating on standard mode upto 100 kbits/s and fast + mode upto 400 kbits/s. + config SYS_I2C_ROCKCHIP bool "Rockchip I2C driver" depends on DM_I2C I miss here junks, which move this symbol from the board config file into their defconfig file ... Can you add this please? You can use the great script from Masahiro for this task: tools/moveconfig.py bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] SPL: create Kconfig options for CONFIG_SPL_*_LOAD
In order to clean up the config headers and also to allow to easily switch the boot device for some boards without having to modify the config headers, it is better to move the options to Kconfig. This commit move the CONFIG_SPL_*_LOAD options to Kconfig files. Signed-off-by: Fabien Parent --- common/spl/Kconfig | 25 + scripts/config_whitelist.txt | 3 --- 2 files changed, 25 insertions(+), 3 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index cba51f5df6..9313870566 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -97,6 +97,31 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR Address on the MMC to load U-Boot from, when the MMC is being used in raw mode. Units: MMC sectors (1 sector = 512 bytes). +config SPL_SELECT_BOOT_MEDIA + bool "Select the media to boot from" + depends on SPL + help + Enable selection of the media that will be used to load u-boot or + the OS. This is not a must, some SoCs need this, some not. + +choice + prompt "Boot media" + depends on SPL_SELECT_BOOT_MEDIA + +config SPL_NAND_LOAD + bool "Load u-boot or OS from NAND" + depends on SPL_NAND_SUPPORT + +config SPL_SPI_LOAD + bool "Load u-boot or OS from SPI" + depends on SPL_SPI_FLASH_SUPPORT + +config SPL_MMC_LOAD + bool "Load u-boot or OS from MMC" + depends on SPL_MMC_SUPPORT + +endchoice + config TPL bool depends on SPL && SUPPORT_TPL diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 8814841e1f..f9fb4b59f8 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -4163,7 +4163,6 @@ CONFIG_SPL_MAX_FOOTPRINT CONFIG_SPL_MAX_PEB_SIZE CONFIG_SPL_MAX_SIZE CONFIG_SPL_MMC_BOOT -CONFIG_SPL_MMC_LOAD CONFIG_SPL_MMC_MINIMAL CONFIG_SPL_MPC83XX_WAIT_FOR_NAND CONFIG_SPL_MXS_PSWITCH_WAIT @@ -4173,7 +4172,6 @@ CONFIG_SPL_NAND_BOOT CONFIG_SPL_NAND_DRIVERS CONFIG_SPL_NAND_ECC CONFIG_SPL_NAND_INIT -CONFIG_SPL_NAND_LOAD CONFIG_SPL_NAND_MINIMAL CONFIG_SPL_NAND_MXS CONFIG_SPL_NAND_RAW_ONLY @@ -4199,7 +4197,6 @@ CONFIG_SPL_SKIP_RELOCATE CONFIG_SPL_SPAACT_ADDR CONFIG_SPL_SPI_BOOT CONFIG_SPL_SPI_FLASH_MINIMAL -CONFIG_SPL_SPI_LOAD CONFIG_SPL_STACK CONFIG_SPL_STACK_ADDR CONFIG_SPL_STACK_SIZE -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] davinci: spl: use correct macro to select boot device
The macro used to select the boot device is not the intended one. It
should be CONFIG_SPL_NAND_LOAD and not CONFIG_SPL_NAND_SIMPLE.
Using the correct config option will help move them to Kconfig option.
Every davinci board that use the SPL are defining both
CONFIG_SPL_NAND_LOAD and CONFIG_SPL_NAND_SIMPLE at the same place, so
there should be no issue created by this change.
Signed-off-by: Fabien Parent
---
arch/arm/mach-davinci/spl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/spl.c b/arch/arm/mach-davinci/spl.c
index 0aeaa7d8b7..9d5a173701 100644
--- a/arch/arm/mach-davinci/spl.c
+++ b/arch/arm/mach-davinci/spl.c
@@ -52,7 +52,7 @@ u32 spl_boot_mode(const u32 boot_device)
u32 spl_boot_device(void)
{
-#ifdef CONFIG_SPL_NAND_SIMPLE
+#ifdef CONFIG_SPL_NAND_LOAD
return BOOT_DEVICE_NAND;
#elif defined(CONFIG_SPL_SPI_LOAD)
return BOOT_DEVICE_SPI;
--
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] davinci: omapl138_lcdk: use new CONFIG_SPL_*_LOAD Kconfig options
Instead of defining ourself the config options in the config header, let's use the new Kconfig options for it. Signed-off-by: Fabien Parent --- configs/omapl138_lcdk_defconfig | 1 + include/configs/omapl138_lcdk.h | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig index 52681c92d0..7199d90ae9 100644 --- a/configs/omapl138_lcdk_defconfig +++ b/configs/omapl138_lcdk_defconfig @@ -11,6 +11,7 @@ CONFIG_VERSION_VARIABLE=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_SPL=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5 +CONFIG_SPL_SELECT_BOOT_MEDIA=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="U-Boot > " # CONFIG_CMD_IMLS is not set diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h index 7c2f4141c9..f0b786f394 100644 --- a/include/configs/omapl138_lcdk.h +++ b/include/configs/omapl138_lcdk.h @@ -138,7 +138,6 @@ #define CONFIG_ENV_SPI_MAX_HZ CONFIG_SF_DEFAULT_SPEED #ifdef CONFIG_USE_SPIFLASH -#define CONFIG_SPL_SPI_LOAD #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000 #define CONFIG_SYS_SPI_U_BOOT_SIZE 0x3 #endif @@ -198,7 +197,6 @@ #define CONFIG_SPL_NAND_DRIVERS #define CONFIG_SPL_NAND_ECC #define CONFIG_SPL_NAND_SIMPLE -#define CONFIG_SPL_NAND_LOAD #endif #ifdef CONFIG_SYS_USE_NOR -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] SPL: move CONFIG_SPL_*_LOAD to Kconfig
Moving to CONFIG_SPL_*_LOAD options to Kconfig offers several advantage: * simpler config headers * on some boards we can easily switch to another boot media without needing to modify the config headers. This series fixes an issue in davinci where a wrong option was used in place of a CONFIG_SPL_*_LOAD option, then move the options to Kconfig options, and finally start using these Kconfig options for the OMAPL138-LCDK board. Fabien Parent (3): davinci: spl: use correct macro to select boot device SPL: create Kconfig options for CONFIG_SPL_*_LOAD davinci: omapl138_lcdk: use new CONFIG_SPL_*_LOAD Kconfig options arch/arm/mach-davinci/spl.c | 2 +- common/spl/Kconfig | 25 + configs/omapl138_lcdk_defconfig | 1 + include/configs/omapl138_lcdk.h | 2 -- scripts/config_whitelist.txt| 3 --- 5 files changed, 27 insertions(+), 6 deletions(-) -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] mmc: complete the unfinished move of CONFIG_MMC
On Tue, Dec 06, 2016 at 03:25:46PM +0900, Masahiro Yamada wrote:
> Hi Tom,
>
> 2016-12-06 1:02 GMT+09:00 Tom Rini :
> > On Sun, Dec 04, 2016 at 10:23:10PM +0900, Masahiro Yamada wrote:
> >
> >> Commit 7a777f6d6f35 ("mmc: Add generic Kconfig option") created
> >> a Kconfig entry for this option without any actual moves, then
> >> commit 44c798799f66 ("sunxi: Use Kconfig CONFIG_MMC") moved the
> >> instances only for SUNXI.
> >>
> >> We generally do not like such partial moves. This kind of work
> >> is automated by tools/moveconfig.py, so it is pretty easy to
> >> complete this move.
> >>
> >> This commit was created as follows:
> >>
> >> [1] remove "depends on ARCH_SUNXI || SANDBOX" and
> >> reword the prompt and help message (copied from Linux)
> >> [2] run 'tools/moveconfig MMC'
> >>
> >> Signed-off-by: Masahiro Yamada
> > [snip]
> >> 801 files changed, 630 insertions(+), 197 deletions(-)
> >
> > OK. I think this means that we want MMC to be either default y or
> > default y if ARM || POWERPC || SANDBOX, to cut down on the size here.
>
>
> Nit. s/POWERPC/PPC/
> (Unfortunately, U-Boot historically uses a different
> config for PowerPC.)
Ah right.
> I tried your suggestion.
> It is true that 625 touched defconfigs were decreased to 389,
> but do you think this is a really good idea?
>
> Theoretically, nothing of MMC
> is related to ARM, PowerPC, Sandbox.
>
> I think this is shortening defconfigs
> for the purpose of shortening.
Yes, it is for the purpose of shortening the configs.
> BTW, do you know that
> Kbuild subsystem is discussing a new keyword "imply" ?
>
> https://patchwork.kernel.org/patch/9422463/
>
>
> I am thinking it, if accepted, will be a better solution than
> such unrelated "depends on " or "depends on ".
Adding "imply" could help here I think, yes. The problem is that I want
to make the defaults in Kconfig produce a reasonable defconfig rather
than require each new defconfig to require a lot of information to
produce a reasonable binary. Looking at the imply examples I think that
yes, we could probably get away with doing things like:
arch/Kconfig:
config ARM
bool "ARM Architecture"
...
imply MMC
imply DISPLAY_BOARDINFO
imply DISPLAY_CPUINFO
--
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 06/10] arm: socfpga: arria10: Added drivers for Arria10 Reset Manager
On 12/06/2016 09:08 AM, Chee Tien Fong wrote:
> From: Tien Fong Chee
>
> Drivers for reset manager is restructured such that common functions,
> gen5 drivers and Arria10 drivers are moved to reset_manager.c,
> reset_manager_gen5.c and reset_manager_arria10.c respectively.
>
> Signed-off-by: Tien Fong Chee
> Cc: Marek Vasut
> Cc: Dinh Nguyen
> Cc: Chin Liang See
> Cc: Tien Fong
> ---
> arch/arm/mach-socfpga/Makefile | 16 +-
> arch/arm/mach-socfpga/include/mach/reset_manager.h | 164 --
> arch/arm/mach-socfpga/reset_manager.c | 114 +---
> arch/arm/mach-socfpga/reset_manager_arria10.c | 766
>
> arch/arm/mach-socfpga/reset_manager_gen5.c | 116 +++
> 5 files changed, 1017 insertions(+), 159 deletions(-)
> create mode 100644 arch/arm/mach-socfpga/reset_manager_arria10.c
> create mode 100644 arch/arm/mach-socfpga/reset_manager_gen5.c
>
> diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
> index 809cd47..b8fcf6e 100644
> --- a/arch/arm/mach-socfpga/Makefile
> +++ b/arch/arm/mach-socfpga/Makefile
> @@ -2,21 +2,27 @@
> # (C) Copyright 2000-2003
> # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> #
> -# Copyright (C) 2012 Altera Corporation
> +# Copyright (C) 2012-2016 Altera Corporation
> #
> # SPDX-License-Identifier: GPL-2.0+
> #
>
> obj-y+= misc.o timer.o reset_manager.o system_manager.o
> clock_manager.o \
> fpga_manager.o board.o
> +obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o
> +obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += scan_manager.o wrap_pll_config.o \
> + reset_manager_gen5.o
>
> -obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
> +ifdef CONFIG_SPL_BUILD
> +obj-y += spl.o
> +obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += freeze_controller.o wrap_iocsr_config.o
> \
> + wrap_pinmux_config.o wrap_sdram_config.o
> +endif
>
> +ifdef CONFIG_TARGET_SOCFPGA_GEN5
> # QTS-generated config file wrappers
> -obj-$(CONFIG_TARGET_SOCFPGA_GEN5)+= scan_manager.o wrap_pll_config.o
> -obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o \
> -wrap_sdram_config.o
> CFLAGS_wrap_iocsr_config.o += -I$(srctree)/board/$(BOARDDIR)
> CFLAGS_wrap_pinmux_config.o += -I$(srctree)/board/$(BOARDDIR)
> CFLAGS_wrap_pll_config.o += -I$(srctree)/board/$(BOARDDIR)
> CFLAGS_wrap_sdram_config.o += -I$(srctree)/board/$(BOARDDIR)
> +endif
> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> index 6225118..077391a 100644
> --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> @@ -1,19 +1,32 @@
> /*
> - * Copyright (C) 2012 Altera Corporation
> + * Copyright (C) 2012-2016 Altera Corporation
> *
> - * SPDX-License-Identifier: GPL-2.0+
> + * SPDX-License-Identifier: GPL-2.0
License change ?
> */
>
> #ifndef _RESET_MANAGER_H_
> #define _RESET_MANAGER_H_
>
> -void reset_cpu(ulong addr);
> -void reset_deassert_peripherals_handoff(void);
> +/* Common function prototypes */
> +extern void reset_cpu(ulong addr);
> +extern void socfpga_bridges_reset(int enable);
> +extern void socfpga_per_reset(u32 reset, int set);
> +extern void socfpga_per_reset_all(void);
Drop the extern ...
> -void socfpga_bridges_reset(int enable);
> -
> -void socfpga_per_reset(u32 reset, int set);
> -void socfpga_per_reset_all(void);
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> +extern void reset_deassert_peripherals_handoff(void);
> +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> +extern void watchdog_disable(void);
> +extern void reset_deassert_noc_ddr_scheduler(void);
> +extern int is_wdt_in_reset(void);
> +extern void emac_manage_reset(ulong emacbase, uint state);
> +extern int reset_deassert_bridges_handoff(void);
> +extern void reset_deassert_dedicated_peripherals(void);
> +extern void reset_assert_fpga_connected_peripherals(void);
> +extern void reset_deassert_fpga_connected_peripherals(void);
> +extern void reset_deassert_shared_connected_peripherals(void);
> +extern void reset_deassert_osc1wd0(void);
> +#endif
>
> #if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> struct socfpga_reset_manager {
> @@ -29,40 +42,40 @@ struct socfpga_reset_manager {
> u32 padding2[12];
> u32 tstscratch;
> };
> -#else
> +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> struct socfpga_reset_manager {
> - u32 stat;
> - u32 ramstat;
> - u32 miscstat;
> - u32 ctrl;
> - u32 hdsken;
> - u32 hdskreq;
> - u32 hdskack;
> - u32 counts;
> - u32 mpu_mod_reset;
> - u32 per_mod_reset; /* stated as per0_mod_reset in A10 datasheet */
> - u32 per2_mod_reset; /* stated as per1_mod_reset in A10 datasheet */
> - u32 brg_mod_reset;
> - u32 misc_mod_reset;
Re: [U-Boot] [PATCH 03/10] arm: socfpga: arria10: Enhanced socfpga_arria10_defconfig to support SPL
On 12/06/2016 08:52 AM, Chee Tien Fong wrote: > From: Tien Fong Chee > > Enhanced defconfig file for Arria10 to enable SPL build and supporting > device tree build for SDMMC. > > Signed-off-by: Tien Fong Chee > Cc: Marek Vasut > Cc: Dinh Nguyen > Cc: Chin Liang See > Cc: Tien Fong > --- > arch/arm/mach-socfpga/include/mach/boot0.h | 17 + > configs/socfpga_arria10_defconfig | 18 +- > 2 files changed, 30 insertions(+), 5 deletions(-) > create mode 100644 arch/arm/mach-socfpga/include/mach/boot0.h > > diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h > b/arch/arm/mach-socfpga/include/mach/boot0.h > new file mode 100644 > index 000..8052a0b > --- /dev/null > +++ b/arch/arm/mach-socfpga/include/mach/boot0.h > @@ -0,0 +1,17 @@ > +/* > + * Copyright (C) 2016, Intel Corporation > + * > + * SPDX-License-Identifier: GPL-2.0 > + */ > + > +#ifndef __BOOT0_H > +#define __BOOT0_H > + > +#if (defined(CONFIG_ARCH_SOCFPGA) && defined(CONFIG_SPL_BUILD)) > +/* BOOT0 header information */ > +#define ARM_SOC_BOOT0_HOOK \ > + .fill 12, 4, 0xdeadbeef Seems unrelated and something that was fixed in mainline already. > +#else > +#define ARM_SOC_BOOT0_HOOK > +#endif > +#endif /* __BOOT0_H */ > diff --git a/configs/socfpga_arria10_defconfig > b/configs/socfpga_arria10_defconfig > index 422261b..755bb66 100644 > --- a/configs/socfpga_arria10_defconfig > +++ b/configs/socfpga_arria10_defconfig > @@ -3,14 +3,22 @@ CONFIG_ARCH_SOCFPGA=y > CONFIG_TARGET_SOCFPGA_ARRIA10=y > CONFIG_DM_GPIO=y > CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y > -CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk" > +CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" > +CONFIG_IDENT_STRING="socfpga_arria10" > # CONFIG_CMD_IMLS is not set > # CONFIG_CMD_FLASH is not set > CONFIG_CMD_GPIO=y > CONFIG_DWAPB_GPIO=y > -CONFIG_DM_ETH=y > -CONFIG_ETH_DESIGNWARE=y > CONFIG_SYS_NS16550=y > -CONFIG_CADENCE_QSPI=y > -CONFIG_DESIGNWARE_SPI=y > CONFIG_DM_MMC=y > +CONFIG_SYS_MALLOC_F_LEN=0x2000 > +CONFIG_CMD_MMC=y > +CONFIG_USE_TINY_PRINTF=y > +CONFIG_SPL=y > +CONFIG_SPL_DM=y > +CONFIG_SPL_SIMPLE_BUS=y > +CONFIG_SPL_DM_SEQ_ALIAS=y > +CONFIG_SPL_MMC_SUPPORT=y > +CONFIG_SPL_SERIAL_SUPPORT=y > +CONFIG_SPL_OF_LIBFDT=y > +CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y > -- 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 05/10] arm: socfpga: arria10: Added support for Arria 10 SoC dev kit
On 12/06/2016 09:07 AM, Chee Tien Fong wrote: > From: Tien Fong Chee > > Signed-off-by: Tien Fong Chee > Cc: Marek Vasut > Cc: Dinh Nguyen > Cc: Chin Liang See > Cc: Tien Fong > --- > arch/arm/mach-socfpga/include/mach/base_addr_a10.h | 11 +- > arch/arm/mach-socfpga/system_manager.c |4 +- > drivers/fpga/socfpga.c |7 +- > include/configs/socfpga_arria10_socdk.h| 152 +-- > 4 files changed, 151 insertions(+), 23 deletions(-) > > diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_a10.h > b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h > index 902c321..487a5dc 100644 > --- a/arch/arm/mach-socfpga/include/mach/base_addr_a10.h > +++ b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h > @@ -1,7 +1,7 @@ > /* > - * Copyright (C) 2014 Altera Corporation > + * Copyright (C) 2014-2016 Altera Corporation > * > - * SPDX-License-Identifier: GPL-2.0+ > + * SPDX-License-Identifier: GPL-2.0 Can you change license this way ? > */ > > #ifndef _SOCFPGA_A10_BASE_HARDWARE_H_ > @@ -35,11 +35,14 @@ > > #define SOCFPGA_ECC_OCRAM_ADDRESS0xff8c3000 > #define SOCFPGA_UART0_ADDRESS0xffc02000 > -#define SOCFPGA_OSC1TIMER0_ADDRESS 0xffd0 > +#define SOCFPGA_SYSTIMER0_ADDRESS0xffd0 > +#define SOCFPGA_SYSTIMER1_ADDRESS0xffd00100 > #define SOCFPGA_CLKMGR_ADDRESS 0xffd04000 > #define SOCFPGA_RSTMGR_ADDRESS 0xffd05000 This should be in a separate patch. > -#define SOCFPGA_SDR_ADDRESS 0xffcfb000 > +#define SOCFPGA_SDR_ADDRESS 0xffcfb000 > +#define SOCFPGA_NOC_L4_PRIV_FLT_OFST0xffd11000 > +#define SOCFPGA_NOC_FW_H2F_SCR_OFST 0xffd13500 > #define SOCFPGA_SDR_SCHEDULER_ADDRESS0xffd12400 > #define SOCFPGA_SDR_FIREWALL_OCRAM_ADDRESS 0xffd13200 > #define SOCFPGA_SDR_FIREWALL_MPU_FPGA_ADDRESS0xffd13300 > diff --git a/arch/arm/mach-socfpga/system_manager.c > b/arch/arm/mach-socfpga/system_manager.c > index 9e1c3fd..e1f0082 100644 > --- a/arch/arm/mach-socfpga/system_manager.c > +++ b/arch/arm/mach-socfpga/system_manager.c This should also be in a separate patch, don't go hacking common code in board-support patch. > @@ -1,5 +1,5 @@ > /* > - * Copyright (C) 2013 Altera Corporation > + * Copyright (C) 2013-2016 Altera Corporation > * > * SPDX-License-Identifier: GPL-2.0+ > */ > @@ -11,8 +11,10 @@ > > DECLARE_GLOBAL_DATA_PTR; > > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5) > static struct socfpga_system_manager *sysmgr_regs = > (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS; > +#endif > > /* > * Populate the value for SYSMGR.FPGAINTF.MODULE based on pinmux setting. > diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c > index bfefafd..7fd922e 100644 > --- a/drivers/fpga/socfpga.c > +++ b/drivers/fpga/socfpga.c > @@ -1,5 +1,5 @@ > /* > - * Copyright (C) 2012 Altera Corporation > + * Copyright (C) 2012-2016 Altera Corporation > * All rights reserved. > * > * SPDX-License-Identifier: BSD-3-Clause > @@ -19,8 +19,10 @@ DECLARE_GLOBAL_DATA_PTR; > > static struct socfpga_fpga_manager *fpgamgr_regs = > (struct socfpga_fpga_manager *)SOCFPGA_FPGAMGRREGS_ADDRESS; > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5) > static struct socfpga_system_manager *sysmgr_regs = > (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS; > +#endif > > /* Set CD ratio */ > static void fpgamgr_set_cd_ratio(unsigned long ratio) > @@ -267,9 +269,10 @@ int socfpga_load(Altera_desc *desc, const void > *rbf_data, size_t rbf_size) > } > > /* Prior programming the FPGA, all bridges need to be shut off */ > - > +#if defined(CONFIG_TARGET_SOCFPGA_GEN5) > /* Disable all signals from hps peripheral controller to fpga */ > writel(0, &sysmgr_regs->fpgaintfgrp_module); > +#endif > > /* Disable all signals from FPGA to HPS SDRAM */ > #define SDR_CTRLGRP_FPGAPORTRST_ADDRESS 0x5080 > diff --git a/include/configs/socfpga_arria10_socdk.h > b/include/configs/socfpga_arria10_socdk.h > index 577f60f..15c7a28 100644 > --- a/include/configs/socfpga_arria10_socdk.h > +++ b/include/configs/socfpga_arria10_socdk.h > @@ -1,5 +1,5 @@ > /* > - * Copyright (C) 2015 Altera Corporation > + * Copyright (C) 2015-2016 Altera Corporation > * > * SPDX-License-Identifier: GPL-2.0 > */ > @@ -16,36 +16,67 @@ > > #define CONFIG_CMD_ASKENV > #define CONFIG_CMD_BOOTZ > -#define CONFIG_CMD_CACHE > -#define CONFIG_CMD_DHCP > #define CONFIG_CMD_EXT4 > #define CONFIG_CMD_EXT4_WRITE > -#define CONFIG_CMD_FAT > -#define CONFIG_CMD_FS_GENERIC > #define CONFIG_CMD_GREPENV > -#define CONFIG_CMD_MMC > #define CONFIG_CMD_PING > > -/* > - * Memory configurations > - */ > -#define PHYS_SDRAM_1_SIZE0x200 > - > /* Booting Linux */ > -#define CONFI
Re: [U-Boot] [PATCH 04/10] arm: socfpga: arria10: Added clock manager and pin mux compat macro
On 12/06/2016 08:52 AM, Chee Tien Fong wrote:
> From: Tien Fong Chee
>
> These compat macros would be used by clock manager and pin mux drivers
> to look the required HW info from DTS for hardware initialization.
>
> Signed-off-by: Tien Fong Chee
> Cc: Marek Vasut
> Cc: Dinh Nguyen
> Cc: Chin Liang See
> Cc: Tien Fong
> ---
> include/fdtdec.h |8
> lib/fdtdec.c |2 ++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 27887c8..68cb199 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -155,6 +155,14 @@ enum fdt_compat_id {
> COMPAT_INTEL_BAYTRAIL_FSP_MDP, /* Intel FSP memory-down params */
> COMPAT_INTEL_IVYBRIDGE_FSP, /* Intel Ivy Bridge FSP */
> COMPAT_SUNXI_NAND, /* SUNXI NAND controller */
> + COMPAT_ALTERA_SOCFPGA_CLK, /* SoCFPGA Clock initialization */
> + COMPAT_ALTERA_SOCFPGA_PINCTRL_SINGLE, /* pinctrl-single */
> + COMPAT_ALTERA_SOCFPGA_H2F_BRG, /* Arria10 hps2fpga bridge */
> + COMPAT_ALTERA_SOCFPGA_LWH2F_BRG,/* Arria10 lwhps2fpga bridge */
> + COMPAT_ALTERA_SOCFPGA_F2H_BRG, /* Arria10 fpga2hps bridge */
> + COMPAT_ALTERA_SOCFPGA_F2SDR0, /* Arria10 fpga2SDRAM0 bridge */
> + COMPAT_ALTERA_SOCFPGA_F2SDR1, /* Arria10 fpga2SDRAM1 bridge */
> + COMPAT_ALTERA_SOCFPGA_F2SDR2, /* Arria10 fpga2SDRAM2 bridge */
Is all of this needed ? You're only adding two entries in the FDTDEC below.
>
> COMPAT_COUNT,
> };
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 4defb90..09a1db4 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -66,6 +66,8 @@ static const char * const compat_names[COMPAT_COUNT] = {
> COMPAT(INTEL_BAYTRAIL_FSP_MDP, "intel,baytrail-fsp-mdp"),
> COMPAT(INTEL_IVYBRIDGE_FSP, "intel,ivybridge-fsp"),
> COMPAT(COMPAT_SUNXI_NAND, "allwinner,sun4i-a10-nand"),
> + COMPAT(ALTERA_SOCFPGA_CLK, "altr,clk-mgr"),
> + COMPAT(ALTERA_SOCFPGA_PINCTRL_SINGLE, "pinctrl-single"),
> };
>
> const char *fdtdec_get_compatible(enum fdt_compat_id id)
>
--
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 01/10] ARM:dts: Added device tree for socfpga arria10 development kit sdmmc
On 12/06/2016 08:50 AM, Chee Tien Fong wrote: > From: Tien Fong Chee > > This is initial version of device tree for the Intel socfpga arria10 > development kit with sdmmc. > > Signed-off-by: Tien Fong Chee > Cc: Marek Vasut > Cc: Dinh Nguyen > Cc: Chin Liang See > Cc: Tien Fong > --- > arch/arm/dts/Makefile |3 +- > arch/arm/dts/socfpga_arria10.dtsi | 859 > +++ > arch/arm/dts/socfpga_arria10_handoff_sdmmc.dtsi | 473 + > arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts| 33 + > 4 files changed, 1367 insertions(+), 1 deletions(-) > create mode 100644 arch/arm/dts/socfpga_arria10.dtsi > create mode 100644 arch/arm/dts/socfpga_arria10_handoff_sdmmc.dtsi Isn't the handoff file board-specific ? > create mode 100644 arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts Does this patchset somehow supersede the previous one [1] or what is the plan here ? [1] http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/01-arria10 -- 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 v3 11/11] spi: cadence_qspi: Support specifying the sample edge used
On 12/06/2016 11:25 AM, Phil Edworthy wrote: > Hi Marek, > > On 05 December 2016 13:31, Marek Vasut wrote: >> On 12/05/2016 11:46 AM, Phil Edworthy wrote: >>> On 05 December 2016 10:42, Jagan Teki wrote: On Mon, Dec 5, 2016 at 11:31 AM, Phil Edworthy wrote: > On 05 December 2016 10:26, Jagan Teki wrote: >> On Mon, Dec 5, 2016 at 11:09 AM, Phil Edworthy >> wrote: >>> On 02 December 2016 14:23, Jagan Teki wrote: On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy wrote: > Introduce a new DT property to specify whether the QSPI Controller > samples the data on a rising edge. The default is falling edge. > Some versions of the QSPI Controller do not implement this bit, in > which case the property should be omitted. > > Signed-off-by: Phil Edworthy > --- > v3: > - Patch split so this one only has code related to the subject. > - Commit message updated. > v2: > - Change name of DT prop and provide details of what it does. > Whilst at it, move the code to read the "sram-size" property > into the other code that reads properties from the node, rather > than the SF subnode. > > Also change the code to use a bool for the bypass arg. > --- > doc/device-tree-bindings/spi/spi-cadence.txt | 2 ++ > drivers/spi/cadence_qspi.c | 10 +++--- > drivers/spi/cadence_qspi.h | 3 ++- > drivers/spi/cadence_qspi_apb.c | 8 +++- > 4 files changed, 18 insertions(+), 5 deletions(-) > > diff --git a/doc/device-tree-bindings/spi/spi-cadence.txt > b/doc/device- tree- bindings/spi/spi-cadence.txt > index c1e2233..94c800b 100644 > --- a/doc/device-tree-bindings/spi/spi-cadence.txt > +++ b/doc/device-tree-bindings/spi/spi-cadence.txt > @@ -26,3 +26,5 @@ connected flash properties > select (n_ss_out). > - tslch-ns : Delay in master reference clocks between > setting > n_ss_out low and first bit transfer > +- sample-edge-rising : Data outputs from flash memory will be >> sampled on the > + rising edge. Default is falling edge. Code look reasonable, but how Linux handling this with the same dt property, any idea? I couldn't find it either. >>> The Linux driver does not yet have this property. Is there a policy to >>> add >> new >>> props to Linux first? >> >> If the same/equal code used in Linux better to have the same property >> instead of another name used in U-boot? > Of course, but I cannot see this in Linux: > https://git.kernel.org/cgit/linux/kernel/git/next/linux- next.git/tree/Documentation/devicetree/bindings/spi/spi-cadence.txt Yeah, I saw this. Do you have any idea how Linux handling this sample edge? >>> The same way U-Boot currently handles it, i.e. it does nothing with this. >> Intel/Altera >>> (Chin Liang) said that they do not have this bit in their version of the >>> Cadence >> QSPI >>> Controller. >>> >>> We are using a later version that has had this bit added. >> >> You were looking at the wrong bindings: >> https://git.kernel.org/cgit/linux/kernel/git/next/linux- >> next.git/tree/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt > Thanks for pointing that out! > >> but yes, Linux does not do support the data edge toggling. I think there >> was another QSPI patch in Linux which tried adding such property, so >> check linux-mtd for it. Generic one would be great. > I had a search around, but couldn't find anything. Look for negative_edge here: http://www.spinics.net/lists/devicetree/msg153582.html >> And no, there is no policy for pushing new props to linux first. New DT >> props should ideally get approved via devicetree@vger though, but that's >> about it. Also, while I tried backporting the Linux CQSPI driver to >> U-Boot, but unfortunately, it turned out to be extremely difficult due >> significant differences between the Linux and U-Boot SPI NOR framework. > OK, thanks for the information. > > Thanks > Phil > -- 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 02/10] arm: socfpga: arria10: Added config option build for SPL
On 12/06/2016 08:52 AM, Chee Tien Fong wrote: > From: Tien Fong Chee > > These changes to ensure Arria10 SPL build success. Please reword the commit message, mention you're removing the Arria10 bits. Still, this does not even apply on mainline, on top of what does this apply ? > Signed-off-by: Tien Fong Chee > Cc: Marek Vasut > Cc: Dinh Nguyen > Cc: Chin Liang See > Cc: Tien Fong > --- > arch/arm/Kconfig |8 > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 220bb19..05ce8b8 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -622,12 +622,12 @@ config ARCH_SNAPDRAGON > config ARCH_SOCFPGA > bool "Altera SOCFPGA family" > select CPU_V7 > - select SUPPORT_SPL if !TARGET_SOCFPGA_ARRIA10 > + select SUPPORT_SPL > select OF_CONTROL > - select SPL_OF_CONTROL if !TARGET_SOCFPGA_ARRIA10 > + select SPL_OF_CONTROL > select DM > - select DM_SPI_FLASH > - select DM_SPI > + select DM_SPI_FLASH if !TARGET_SOCFPGA_ARRIA10 > + select DM_SPI if !TARGET_SOCFPGA_ARRIA10 > > config TARGET_CM_T43 > bool "Support cm_t43" > -- 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 v3 3/4] mmc: zynq: Determine base clock frequency via clock framework
On 5.12.2016 23:22, Jaehoon Chung wrote: > On 12/02/2016 10:24 PM, stefan.herbrechtsme...@weidmueller.de wrote: >> From: Stefan Herbrechtsmeier >> >> The zynq_sdhci controller driver use CONFIG_ZYNQ_SDHCI_MAX_FREQ as base >> clock frequency but this clock is not fixed and depends on the hardware >> configuration. Additionally the value of CONFIG_ZYNQ_SDHCI_MAX_FREQ >> doesn't match the real base clock frequency of SDIO_FREQ. Use the clock >> framework to determine the frequency at run time. >> >> Signed-off-by: Stefan Herbrechtsmeier > > > Even if this patch is delegated to Michal, i picked to this. > Applied on u-boot-mmc. > Based on my reply in v2 this is not ideal patch http://lists.denx.de/pipermail/u-boot/2016-November/274310.html Not a problem to take these patches should mmc tree but please wait till you have Ack from me. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 23/23] sunxi: A64: add 32-bit SPL support
Hi, On 06/12/16 11:28, Maxime Ripard wrote: > On Mon, Dec 05, 2016 at 01:52:30AM +, Andre Przywara wrote: >> When compiling the SPL for the Allwinner A64 in AArch64 mode, we can't >> use the more compact Thumb2 encoding, which only exists for AArch32 >> code. This makes the SPL rather big, up to a point where any code >> additions or even a different compiler may easily exceed the 32KB limit >> that the Allwinner BROM imposes. >> Introduce a separate, mostly generic sun50i-a64 configuration, which >> defines the CPU_V7 symbol and thus will create a 32-bit binary using >> the memory-saving Thumb2 encoding. > > "mostly generic". Where do you draw the line? How do you deal with a > board that would use a different UART? a different MMC? different > memory configuration.? My impression was that it's rather pointless to provide another set of 32-bit SPL defconfigs for each board again, especially given that for the SPL's needs the boards so far seem to be very similar. For the loading part we will probably go with what the BROM already started: load more data from one of the BROM boot sources, which is fixed in the SoC and can't be really changed by a board vendor anyway. Which really leaves the DRAM setup and the UART. I can't predict the future, but so far those A64 boards look fairly similar in this respect. So I just avoid having another SPL defconfig for the BananaPi M64, for instance. I just added MMC_SUNXI_SLOT_EXTRA because this doesn't hurt on the Pine64, so less churn here. So if you know of any board which breaks this assumption, I am happy to hear about it and see if it can be integrated. Actually I had the idea of eventually going the other way around: Providing one U-Boot proper A64 defconfig and let the DT (provided by the SPL) sort out the differences. Then we might be able to live with separate SPL defconfigs. But that's another patchset and probably quite some work. > This looks like it's not generic at all, it's just a configuration for > the Pine64. And the BananaPi M64. And the upcoming Olimex board (trusting their latest published schematics). If in need, we can always provide separate defconfigs for "odd" boards. So this is the best solution I came up with, if you have a better one: I am all ears. Would it make sense to rename this file to not claim universal coverage? Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/23] armv8: add lowlevel_init.S
On Tue, Dec 06, 2016 at 08:04:24AM +, André Przywara wrote: > On 05/12/16 21:56, Tom Rini wrote: > > On Mon, Dec 05, 2016 at 01:52:10AM +, Andre Przywara wrote: > > > >> For boards that call s_init() when the SPL runs, we are expected to > >> setup an early stack before calling this C function. > >> Implement the proper AArch64 version of this based on the ARMv7 code. > >> This allows sunxi boards to setup the basic peripherals even on with a > >> 64-bit SPL. > >> > >> Signed-off-by: Andre Przywara > > > > This is going to override lowlevel_init from arch/arm/cpu/armv8/start.S > > and is that really desired? Thanks! > > Not sure if it is desired, but it's needed. The weak function in start.S > just initialises the GIC (if configured), that looks like a NOP for > sunxi to me (we do this already much better in ARM Trusted Firmware). > For 32-bit sunxi we call s_init() through lowlevel_init(), which is what > I copy here for armv8. > Now there is this comment which discourages doing so and Alex already > complained about it as well, so I might take a look at how we would skip > this step. I was a bit wary going there as this would mean to rework the > 32-bit code as well, which affects a lot of boards, which I can barely > test here. The path flow here on 32bit, both with and without SPL is what makes this area a good bit of a pain to make changes in. -- 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 10/10] arm: socfpga: arria10: Added Arria10 critical HW initialization to spl
From: Tien Fong Chee
This patch adding the Arria10 critical hardware initialization before
enabling console print out in spl.
Signed-off-by: Tien Fong Chee
Cc: Marek Vasut
Cc: Dinh Nguyen
Cc: Chin Liang See
Cc: Tien Fong
---
arch/arm/mach-socfpga/spl.c | 86 +-
1 files changed, 83 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
index fec4c7a..9375514 100644
--- a/arch/arm/mach-socfpga/spl.c
+++ b/arch/arm/mach-socfpga/spl.c
@@ -1,7 +1,7 @@
/*
- * Copyright (C) 2012 Altera Corporation
+ * Copyright (C) 2012-2016 Altera Corporation
*
- * SPDX-License-Identifier:GPL-2.0+
+ * SPDX-License-Identifier:GPL-2.0
*/
#include
@@ -19,22 +19,32 @@
#include
#include
#include
+#include
+#include
+#include
+#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
+#include
+#endif
DECLARE_GLOBAL_DATA_PTR;
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
static struct pl310_regs *const pl310 =
(struct pl310_regs *)CONFIG_SYS_PL310_BASE;
static struct scu_registers *scu_regs =
(struct scu_registers *)SOCFPGA_MPUSCU_ADDRESS;
static struct nic301_registers *nic301_regs =
(struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
-static struct socfpga_system_manager *sysmgr_regs =
+#endif
+
+static const struct socfpga_system_manager *sysmgr_regs =
(struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
u32 spl_boot_device(void)
{
const u32 bsel = readl(&sysmgr_regs->bootinfo);
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
switch (bsel & 0x7) {
case 0x1: /* FPGA (HPS2FPGA Bridge) */
return BOOT_DEVICE_RAM;
@@ -55,6 +65,24 @@ u32 spl_boot_device(void)
printf("Invalid boot device (bsel=%08x)!\n", bsel);
hang();
}
+#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
+ switch ((bsel>>12) & 0x7) {
+ case 0x1: /* FPGA (HPS2FPGA Bridge) */
+ return BOOT_DEVICE_RAM;
+ case 0x2: /* NAND Flash (1.8V) */
+ case 0x3: /* NAND Flash (3.0V) */
+ return BOOT_DEVICE_NAND;
+ case 0x4: /* SD/MMC External Transceiver (1.8V) */
+ case 0x5: /* SD/MMC Internal Transceiver (3.0V) */
+ return BOOT_DEVICE_MMC1;
+ case 0x6: /* QSPI Flash (1.8V) */
+ case 0x7: /* QSPI Flash (3.0V) */
+ return BOOT_DEVICE_SPI;
+ default:
+ printf("Invalid boot device (bsel=%08x)!\n", bsel);
+ hang();
+ }
+#endif
}
#ifdef CONFIG_SPL_MMC_SUPPORT
@@ -68,6 +96,7 @@ u32 spl_boot_mode(const u32 boot_device)
}
#endif
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
static void socfpga_nic301_slave_ns(void)
{
writel(0x1, &nic301_regs->lwhps2fpgaregs);
@@ -182,3 +211,54 @@ void board_init_f(ulong dummy)
/* Configure simple malloc base pointer into RAM. */
gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024);
}
+#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
+void board_init_f(ulong dummy)
+{
+ memset(__bss_start, 0, __bss_end - __bss_start);
+ /*
+* Configure Clock Manager to use intosc clock instead external osc to
+* ensure success watchdog operation. We do it as early as possible.
+*/
+ cm_use_intosc();
+
+ watchdog_disable();
+
+ arch_early_init_r();
+
+#ifdef CONFIG_HW_WATCHDOG
+ /* release osc1 watchdog timer 0 from reset */
+ reset_deassert_osc1wd0();
+
+ /* reconfigure and enable the watchdog */
+ hw_watchdog_init();
+ WATCHDOG_RESET();
+#endif /* CONFIG_HW_WATCHDOG */
+
+#ifdef CONFIG_OF_CONTROL
+ /* We need to access to FDT as this stage */
+ /* FDT is at end of image */
+ gd->fdt_blob = (void *)(__bss_end);
+ /* Check whether we have a valid FDT or not. */
+ if (fdtdec_prepare_fdt()) {
+ panic("** CONFIG_OF_CONTROL defined but no FDT - please see "
+ "doc/README.fdt-control");
+ }
+#endif /* CONFIG_OF_CONTROL */
+
+ /* Initialize the timer */
+ timer_init();
+
+ /* configuring the clock based on handoff */
+ cm_basic_init(gd->fdt_blob);
+ WATCHDOG_RESET();
+
+ config_dedicated_pins(gd->fdt_blob);
+ WATCHDOG_RESET();
+
+ /* configure the Reset Manager */
+ reset_deassert_dedicated_peripherals();
+
+ /* enable console uart printing */
+ preloader_console_init();
+}
+#endif
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/10] arm: socfpga: arria10: Added drivers for Arria10 pin mux/pins configuration
From: Tien Fong Chee
Signed-off-by: Tien Fong Chee
Cc: Marek Vasut
Cc: Dinh Nguyen
Cc: Chin Liang See
Cc: Tien Fong
---
arch/arm/mach-socfpga/Makefile |2 +-
arch/arm/mach-socfpga/include/mach/pinmux.h | 17 +
arch/arm/mach-socfpga/pinmux.c | 104 +++
3 files changed, 122 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-socfpga/include/mach/pinmux.h
create mode 100644 arch/arm/mach-socfpga/pinmux.c
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 71cf31c..1ab68be 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -10,7 +10,7 @@
obj-y += misc.o timer.o reset_manager.o system_manager.o clock_manager.o \
fpga_manager.o board.o
obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o misc_arria10.o
\
- clock_manager_arria10.o
+ clock_manager_arria10.o pinmux.o
obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += scan_manager.o wrap_pll_config.o \
reset_manager_gen5.o misc_gen5.o \
clock_manager_gen5.o
diff --git a/arch/arm/mach-socfpga/include/mach/pinmux.h
b/arch/arm/mach-socfpga/include/mach/pinmux.h
new file mode 100644
index 000..e7d831d
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/pinmux.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#ifndef_PINMUX_H_
+#define_PINMUX_H_
+
+#ifndef __ASSEMBLY__
+extern int config_dedicated_pins(const void *blob);
+extern int config_pins(const void *blob, const char *pin_grp);
+#endif
+
+
+
+#endif /* _PINMUX_H_ */
diff --git a/arch/arm/mach-socfpga/pinmux.c b/arch/arm/mach-socfpga/pinmux.c
new file mode 100644
index 000..d45722f
--- /dev/null
+++ b/arch/arm/mach-socfpga/pinmux.c
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include
+#include
+#include
+#include
+
+int config_dedicated_pins(const void *blob);
+int config_pins(const void *blob, const char *pin_grp);
+static int __do_pinctr_pins(const void *blob, int child, const char
*node_name);
+static int do_pinctrl_pins(const void *blob, int node, const char *child_name);
+
+static int __do_pinctr_pins(const void *blob, int child, const char *node_name)
+{
+ int len;
+ fdt_addr_t base_addr;
+ fdt_size_t size;
+ const u32 *cell;
+ u32 offset, value;
+
+ base_addr = fdtdec_get_addr_size(blob, child, "reg", &size);
+ if (base_addr != FDT_ADDR_T_NONE) {
+ cell = fdt_getprop(blob, child, "pinctrl-single,pins",
+ &len);
+ if (cell != NULL) {
+ debug("%p %d\n", cell, len);
+ for (;len > 0; len -= (2*sizeof(u32))) {
+ offset = fdt32_to_cpu(*cell++);
+ value = fdt32_to_cpu(*cell++);
+ debug("<0x%x 0x%x>\n", offset, value);
+ writel(value, base_addr + offset);
+ }
+ return 0;
+ }
+ }
+ return 1;
+}
+
+static int do_pinctrl_pins(const void *blob, int node, const char *child_name)
+{
+ int child, len;
+ const char *node_name;
+
+ child = fdt_first_subnode(blob, node);
+
+ if (child < 0)
+ return 2;
+
+ node_name = fdt_get_name(blob, child, &len);
+
+ while (node_name) {
+ if (!strcmp(child_name, node_name)) {
+ __do_pinctr_pins(blob, child, node_name);
+ return(0);
+ }
+ child = fdt_next_subnode(blob, child);
+
+ if (child < 0)
+ break;
+
+ node_name = fdt_get_name(blob, child, &len);
+ }
+
+ return 1;
+}
+
+int config_dedicated_pins(const void *blob)
+{
+ int node;
+
+ node = fdtdec_next_compatible(blob, 0,
+ COMPAT_ALTERA_SOCFPGA_PINCTRL_SINGLE);
+
+ if (node < 0)
+ return 1;
+
+ if (do_pinctrl_pins(blob, node, "dedicated_cfg"))
+ return 2;
+
+ if (do_pinctrl_pins(blob, node, "dedicated"))
+ return 3;
+
+ return 0;
+}
+
+int config_pins(const void *blob, const char *pin_grp)
+{
+ int node;
+
+ node = fdtdec_next_compatible(blob, 0,
+ COMPAT_ALTERA_SOCFPGA_PINCTRL_SINGLE);
+
+ if (node < 0)
+ return 1;
+
+ if (do_pinctrl_pins(blob, node, pin_grp))
+ return 2;
+
+ return 0;
+}
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/10] arm: socfpga: arria10: Added drivers for Arria10 clock manager
From: Tien Fong Chee
The drivers is restructured such common functions, gen5 functions,
and arria10 functions are moved to clock_manager.c, cock_manager_gen5
and clock_manager_arria10 respectively.
Signed-off-by: Tien Fong Chee
Cc: Marek Vasut
Cc: Dinh Nguyen
Cc: Chin Liang See
Cc: Tien Fong
---
arch/arm/mach-socfpga/Makefile |6 +-
arch/arm/mach-socfpga/clock_manager.c | 754 +++-
arch/arm/mach-socfpga/clock_manager_arria10.c | 954
arch/arm/mach-socfpga/clock_manager_gen5.c | 342 +++
arch/arm/mach-socfpga/include/mach/clock_manager.h | 360 ++--
5 files changed, 1910 insertions(+), 506 deletions(-)
create mode 100644 arch/arm/mach-socfpga/clock_manager_arria10.c
create mode 100644 arch/arm/mach-socfpga/clock_manager_gen5.c
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index f8b529e..71cf31c 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -9,9 +9,11 @@
obj-y += misc.o timer.o reset_manager.o system_manager.o clock_manager.o \
fpga_manager.o board.o
-obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o misc_arria10.o
+obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o misc_arria10.o
\
+ clock_manager_arria10.o
obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += scan_manager.o wrap_pll_config.o \
- reset_manager_gen5.o misc_gen5.o
+ reset_manager_gen5.o misc_gen5.o \
+ clock_manager_gen5.o
ifdef CONFIG_SPL_BUILD
obj-y += spl.o
diff --git a/arch/arm/mach-socfpga/clock_manager.c
b/arch/arm/mach-socfpga/clock_manager.c
index aa71636..fe82c39 100644
--- a/arch/arm/mach-socfpga/clock_manager.c
+++ b/arch/arm/mach-socfpga/clock_manager.c
@@ -1,422 +1,293 @@
/*
- * Copyright (C) 2013 Altera Corporation
+ * Copyright (C) 2013-2016 Intel Corporation
*
- * SPDX-License-Identifier:GPL-2.0+
+ * SPDX-License-Identifier:GPL-2.0
*/
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
+/* Function prototypes */
+/* Common prototypes */
+unsigned int cm_get_l4_sp_clk_hz(void);
+unsigned int cm_get_qspi_controller_clk_hz(void);
+unsigned int cm_get_mmc_controller_clk_hz(void);
+unsigned int cm_get_spi_controller_clk_hz(void);
+static void cm_print_clock_quick_summary(void);
+int do_showclocks(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
+void cm_wait_for_lock(uint32_t mask);
+void cm_wait_for_fsm(void);
+unsigned int cm_get_main_vco_clk_hz(void);
+unsigned int cm_get_per_vco_clk_hz(void);
+unsigned long cm_get_mpu_clk_hz(void);
+
static const struct socfpga_clock_manager *clock_manager_base =
(struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
-static void cm_wait_for_lock(uint32_t mask)
+/* Common functions */
+int set_cpu_clk_info(void)
{
- register uint32_t inter_val;
- uint32_t retry = 0;
- do {
- inter_val = readl(&clock_manager_base->inter) & mask;
- if (inter_val == mask)
- retry++;
- else
- retry = 0;
- if (retry >= 10)
- break;
- } while (1);
-}
+ /* Calculate the clock frequencies required for drivers */
+ cm_get_l4_sp_clk_hz();
+ cm_get_mmc_controller_clk_hz();
-/* function to poll in the fsm busy bit */
-static void cm_wait_for_fsm(void)
-{
- while (readl(&clock_manager_base->stat) & CLKMGR_STAT_BUSY)
- ;
-}
+ gd->bd->bi_arm_freq = cm_get_mpu_clk_hz() / 100;
+ gd->bd->bi_dsp_freq = 0;
-/*
- * function to write the bypass register which requires a poll of the
- * busy bit
- */
-static void cm_write_bypass(uint32_t val)
-{
- writel(val, &clock_manager_base->bypass);
- cm_wait_for_fsm();
-}
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
+ gd->bd->bi_ddr_freq = cm_get_sdram_clk_hz() / 100;
+#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
+ gd->bd->bi_ddr_freq = 0;
+#endif
-/* function to write the ctrl register which requires a poll of the busy bit */
-static void cm_write_ctrl(uint32_t val)
-{
- writel(val, &clock_manager_base->ctrl);
- cm_wait_for_fsm();
+ return 0;
}
-/* function to write a clock register that has phase information */
-static void cm_write_with_phase(uint32_t value,
- uint32_t reg_address, uint32_t mask)
+unsigned int cm_get_spi_controller_clk_hz(void)
{
- /* poll until phase is zero */
- while (readl(reg_address) & mask)
- ;
+ uint32_t clock = 0;
- writel(value, reg_address);
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
+ uint32_t reg;
+ clock = cm_get_per_vco_clk_hz();
- while (readl(reg_address) & mask)
- ;
-}
+ /* get the clock prior L4 SP divider (periph_ba
[U-Boot] [PATCH 07/10] arm: socfpga: arria10: Added miscellaneous drivers for Arria10
From: Tien Fong Chee
The drivers is restructured such common functions, gen5 functions,
and arria10 functions are moved to misc.c, misc_gen5 and misc_arria10
respectively.
Signed-off-by: Tien Fong Chee
Cc: Marek Vasut
Cc: Dinh Nguyen
Cc: Chin Liang See
Cc: Tien Fong
---
arch/arm/mach-socfpga/Makefile|4 +-
arch/arm/mach-socfpga/include/mach/misc.h | 25 ++
arch/arm/mach-socfpga/misc.c | 429 +---
arch/arm/mach-socfpga/misc_arria10.c | 111
arch/arm/mach-socfpga/misc_gen5.c | 363
5 files changed, 517 insertions(+), 415 deletions(-)
create mode 100644 arch/arm/mach-socfpga/include/mach/misc.h
create mode 100644 arch/arm/mach-socfpga/misc_arria10.c
create mode 100644 arch/arm/mach-socfpga/misc_gen5.c
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index b8fcf6e..f8b529e 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -9,9 +9,9 @@
obj-y += misc.o timer.o reset_manager.o system_manager.o clock_manager.o \
fpga_manager.o board.o
-obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o
+obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o misc_arria10.o
obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += scan_manager.o wrap_pll_config.o \
- reset_manager_gen5.o
+ reset_manager_gen5.o misc_gen5.o
ifdef CONFIG_SPL_BUILD
obj-y += spl.o
diff --git a/arch/arm/mach-socfpga/include/mach/misc.h
b/arch/arm/mach-socfpga/include/mach/misc.h
new file mode 100644
index 000..1bf1783
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/misc.h
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2016, Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#ifndef _MISC_H_
+#define_MISC_H_
+
+extern void dwmac_deassert_reset(const unsigned int of_reset_id,
+const u32 phymode);
+
+struct bsel{
+ const char *mode;
+ const char *name;
+};
+
+extern struct bsel bsel_str[];
+
+#ifdef CONFIG_FPGA
+extern void socfpga_fpga_add(void);
+#else
+inline void socfpga_fpga_add(void) {}
+#endif
+#endif /* _MISC_H_ */
diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
index 00e385f..f44233d 100644
--- a/arch/arm/mach-socfpga/misc.c
+++ b/arch/arm/mach-socfpga/misc.c
@@ -1,51 +1,39 @@
/*
- * Copyright (C) 2012 Altera Corporation
+ * Copyright (C) 2012-2016 Altera Corporation
*
- * SPDX-License-Identifier:GPL-2.0+
+ * SPDX-License-Identifier:GPL-2.0
*/
#include
#include
#include
-#include
-#include
#include
#include
#include
#include
+#include
#include
-#include
#include
#include
#include
#include
#include
-#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
-#include
-#else
-#include
-#endif
-
DECLARE_GLOBAL_DATA_PTR;
-static struct pl310_regs *const pl310 =
+static const struct pl310_regs *const pl310 =
(struct pl310_regs *)CONFIG_SYS_PL310_BASE;
-static struct socfpga_system_manager *sysmgr_regs =
- (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
-static struct socfpga_reset_manager *reset_manager_base =
- (struct socfpga_reset_manager *)SOCFPGA_RSTMGR_ADDRESS;
-#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
-static struct nic301_registers *nic301_regs =
- (struct nic301_registers *)SOCFPGA_L3REGS_ADDRESS;
-#else
-static const struct socfpga_noc_fw_ocram *noc_fw_ocram_base =
- (void *)SOCFPGA_SDR_FIREWALL_OCRAM_ADDRESS;
-static const struct socfpga_noc_fw_ddr_l3 *noc_fw_ddr_l3_base =
- (void *)SOCFPGA_SDR_FIREWALL_L3_ADDRESS;
-#endif
-static struct scu_registers *scu_regs =
- (struct scu_registers *)SOCFPGA_MPUSCU_ADDRESS;
+
+struct bselbsel_str[] = {
+ { "rsvd", "Reserved", },
+ { "fpga", "FPGA (HPS2FPGA Bridge)", },
+ { "nand", "NAND Flash (1.8V)", },
+ { "nand", "NAND Flash (3.0V)", },
+ { "sd", "SD/MMC External Transceiver (1.8V)", },
+ { "sd", "SD/MMC Internal Transceiver (3.0V)", },
+ { "qspi", "QSPI Flash (1.8V)", },
+ { "qspi", "QSPI Flash (3.0V)", },
+};
int dram_init(void)
{
@@ -84,219 +72,6 @@ void v7_outer_cache_disable(void)
clrbits_le32(&pl310->pl310_ctrl, L2X0_CTRL_EN);
}
-/*
- * DesignWare Ethernet initialization
- */
-#ifdef CONFIG_ETH_DESIGNWARE
-static void dwmac_deassert_reset(const unsigned int of_reset_id,
-const u32 phymode)
-{
- u32 physhift, reset;
-
- if (of_reset_id == EMAC0_RESET) {
- physhift = SYSMGR_EMACGRP_CTRL_PHYSEL0_LSB;
- reset = SOCFPGA_RESET(EMAC0);
- } else if (of_reset_id == EMAC1_RESET) {
- physhift = SYSMGR_EMACGRP_CTRL_PHYSEL1_LSB;
- reset = SOCFPGA_RESET(EMAC1);
-#ifndef CONFIG_TARGET_SOCFPGA_GEN5
- } else if (of_reset_id == EMAC2_RESET) {
- reset = SOCFPGA_RESET(EMAC2);
[U-Boot] [PATCH 04/10] arm: socfpga: arria10: Added clock manager and pin mux compat macro
From: Tien Fong Chee
These compat macros would be used by clock manager and pin mux drivers
to look the required HW info from DTS for hardware initialization.
Signed-off-by: Tien Fong Chee
Cc: Marek Vasut
Cc: Dinh Nguyen
Cc: Chin Liang See
Cc: Tien Fong
---
include/fdtdec.h |8
lib/fdtdec.c |2 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 27887c8..68cb199 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -155,6 +155,14 @@ enum fdt_compat_id {
COMPAT_INTEL_BAYTRAIL_FSP_MDP, /* Intel FSP memory-down params */
COMPAT_INTEL_IVYBRIDGE_FSP, /* Intel Ivy Bridge FSP */
COMPAT_SUNXI_NAND, /* SUNXI NAND controller */
+ COMPAT_ALTERA_SOCFPGA_CLK, /* SoCFPGA Clock initialization */
+ COMPAT_ALTERA_SOCFPGA_PINCTRL_SINGLE, /* pinctrl-single */
+ COMPAT_ALTERA_SOCFPGA_H2F_BRG, /* Arria10 hps2fpga bridge */
+ COMPAT_ALTERA_SOCFPGA_LWH2F_BRG,/* Arria10 lwhps2fpga bridge */
+ COMPAT_ALTERA_SOCFPGA_F2H_BRG, /* Arria10 fpga2hps bridge */
+ COMPAT_ALTERA_SOCFPGA_F2SDR0, /* Arria10 fpga2SDRAM0 bridge */
+ COMPAT_ALTERA_SOCFPGA_F2SDR1, /* Arria10 fpga2SDRAM1 bridge */
+ COMPAT_ALTERA_SOCFPGA_F2SDR2, /* Arria10 fpga2SDRAM2 bridge */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 4defb90..09a1db4 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -66,6 +66,8 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(INTEL_BAYTRAIL_FSP_MDP, "intel,baytrail-fsp-mdp"),
COMPAT(INTEL_IVYBRIDGE_FSP, "intel,ivybridge-fsp"),
COMPAT(COMPAT_SUNXI_NAND, "allwinner,sun4i-a10-nand"),
+ COMPAT(ALTERA_SOCFPGA_CLK, "altr,clk-mgr"),
+ COMPAT(ALTERA_SOCFPGA_PINCTRL_SINGLE, "pinctrl-single"),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/10] arm: socfpga: arria10: Added drivers for Arria10 Reset Manager
From: Tien Fong Chee
Drivers for reset manager is restructured such that common functions,
gen5 drivers and Arria10 drivers are moved to reset_manager.c,
reset_manager_gen5.c and reset_manager_arria10.c respectively.
Signed-off-by: Tien Fong Chee
Cc: Marek Vasut
Cc: Dinh Nguyen
Cc: Chin Liang See
Cc: Tien Fong
---
arch/arm/mach-socfpga/Makefile | 16 +-
arch/arm/mach-socfpga/include/mach/reset_manager.h | 164 --
arch/arm/mach-socfpga/reset_manager.c | 114 +---
arch/arm/mach-socfpga/reset_manager_arria10.c | 766
arch/arm/mach-socfpga/reset_manager_gen5.c | 116 +++
5 files changed, 1017 insertions(+), 159 deletions(-)
create mode 100644 arch/arm/mach-socfpga/reset_manager_arria10.c
create mode 100644 arch/arm/mach-socfpga/reset_manager_gen5.c
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 809cd47..b8fcf6e 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -2,21 +2,27 @@
# (C) Copyright 2000-2003
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
#
-# Copyright (C) 2012 Altera Corporation
+# Copyright (C) 2012-2016 Altera Corporation
#
# SPDX-License-Identifier: GPL-2.0+
#
obj-y += misc.o timer.o reset_manager.o system_manager.o clock_manager.o \
fpga_manager.o board.o
+obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o
+obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += scan_manager.o wrap_pll_config.o \
+ reset_manager_gen5.o
-obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
+ifdef CONFIG_SPL_BUILD
+obj-y += spl.o
+obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += freeze_controller.o wrap_iocsr_config.o \
+ wrap_pinmux_config.o wrap_sdram_config.o
+endif
+ifdef CONFIG_TARGET_SOCFPGA_GEN5
# QTS-generated config file wrappers
-obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += scan_manager.o wrap_pll_config.o
-obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o\
- wrap_sdram_config.o
CFLAGS_wrap_iocsr_config.o += -I$(srctree)/board/$(BOARDDIR)
CFLAGS_wrap_pinmux_config.o+= -I$(srctree)/board/$(BOARDDIR)
CFLAGS_wrap_pll_config.o += -I$(srctree)/board/$(BOARDDIR)
CFLAGS_wrap_sdram_config.o += -I$(srctree)/board/$(BOARDDIR)
+endif
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 6225118..077391a 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -1,19 +1,32 @@
/*
- * Copyright (C) 2012 Altera Corporation
+ * Copyright (C) 2012-2016 Altera Corporation
*
- * SPDX-License-Identifier:GPL-2.0+
+ * SPDX-License-Identifier:GPL-2.0
*/
#ifndef_RESET_MANAGER_H_
#define_RESET_MANAGER_H_
-void reset_cpu(ulong addr);
-void reset_deassert_peripherals_handoff(void);
+/* Common function prototypes */
+extern void reset_cpu(ulong addr);
+extern void socfpga_bridges_reset(int enable);
+extern void socfpga_per_reset(u32 reset, int set);
+extern void socfpga_per_reset_all(void);
-void socfpga_bridges_reset(int enable);
-
-void socfpga_per_reset(u32 reset, int set);
-void socfpga_per_reset_all(void);
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
+extern void reset_deassert_peripherals_handoff(void);
+#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
+extern void watchdog_disable(void);
+extern void reset_deassert_noc_ddr_scheduler(void);
+extern int is_wdt_in_reset(void);
+extern void emac_manage_reset(ulong emacbase, uint state);
+extern int reset_deassert_bridges_handoff(void);
+extern void reset_deassert_dedicated_peripherals(void);
+extern void reset_assert_fpga_connected_peripherals(void);
+extern void reset_deassert_fpga_connected_peripherals(void);
+extern void reset_deassert_shared_connected_peripherals(void);
+extern void reset_deassert_osc1wd0(void);
+#endif
#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
struct socfpga_reset_manager {
@@ -29,40 +42,40 @@ struct socfpga_reset_manager {
u32 padding2[12];
u32 tstscratch;
};
-#else
+#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
struct socfpga_reset_manager {
- u32 stat;
- u32 ramstat;
- u32 miscstat;
- u32 ctrl;
- u32 hdsken;
- u32 hdskreq;
- u32 hdskack;
- u32 counts;
- u32 mpu_mod_reset;
- u32 per_mod_reset; /* stated as per0_mod_reset in A10 datasheet */
- u32 per2_mod_reset; /* stated as per1_mod_reset in A10 datasheet */
- u32 brg_mod_reset;
- u32 misc_mod_reset; /* stated as sys_mod_reset in A10 datasheet */
- u32 coldmodrst;
- u32 nrstmodrst;
- u32 dbgmodrst;
- u32 mpuwarmmask;
- u32 per0warmmask;
- u32 per1warmmask;
- u32 brgwarmmask;
- u32 syswarmmask;
-
[U-Boot] [PATCH 05/10] arm: socfpga: arria10: Added support for Arria 10 SoC dev kit
From: Tien Fong Chee Signed-off-by: Tien Fong Chee Cc: Marek Vasut Cc: Dinh Nguyen Cc: Chin Liang See Cc: Tien Fong --- arch/arm/mach-socfpga/include/mach/base_addr_a10.h | 11 +- arch/arm/mach-socfpga/system_manager.c |4 +- drivers/fpga/socfpga.c |7 +- include/configs/socfpga_arria10_socdk.h| 152 +-- 4 files changed, 151 insertions(+), 23 deletions(-) diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_a10.h b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h index 902c321..487a5dc 100644 --- a/arch/arm/mach-socfpga/include/mach/base_addr_a10.h +++ b/arch/arm/mach-socfpga/include/mach/base_addr_a10.h @@ -1,7 +1,7 @@ /* - * Copyright (C) 2014 Altera Corporation + * Copyright (C) 2014-2016 Altera Corporation * - * SPDX-License-Identifier:GPL-2.0+ + * SPDX-License-Identifier:GPL-2.0 */ #ifndef _SOCFPGA_A10_BASE_HARDWARE_H_ @@ -35,11 +35,14 @@ #define SOCFPGA_ECC_OCRAM_ADDRESS 0xff8c3000 #define SOCFPGA_UART0_ADDRESS 0xffc02000 -#define SOCFPGA_OSC1TIMER0_ADDRESS 0xffd0 +#define SOCFPGA_SYSTIMER0_ADDRESS 0xffd0 +#define SOCFPGA_SYSTIMER1_ADDRESS 0xffd00100 #define SOCFPGA_CLKMGR_ADDRESS 0xffd04000 #define SOCFPGA_RSTMGR_ADDRESS 0xffd05000 -#define SOCFPGA_SDR_ADDRESS0xffcfb000 +#define SOCFPGA_SDR_ADDRESS0xffcfb000 +#define SOCFPGA_NOC_L4_PRIV_FLT_OFST0xffd11000 +#define SOCFPGA_NOC_FW_H2F_SCR_OFST0xffd13500 #define SOCFPGA_SDR_SCHEDULER_ADDRESS 0xffd12400 #define SOCFPGA_SDR_FIREWALL_OCRAM_ADDRESS 0xffd13200 #define SOCFPGA_SDR_FIREWALL_MPU_FPGA_ADDRESS 0xffd13300 diff --git a/arch/arm/mach-socfpga/system_manager.c b/arch/arm/mach-socfpga/system_manager.c index 9e1c3fd..e1f0082 100644 --- a/arch/arm/mach-socfpga/system_manager.c +++ b/arch/arm/mach-socfpga/system_manager.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2013 Altera Corporation + * Copyright (C) 2013-2016 Altera Corporation * * SPDX-License-Identifier:GPL-2.0+ */ @@ -11,8 +11,10 @@ DECLARE_GLOBAL_DATA_PTR; +#if defined(CONFIG_TARGET_SOCFPGA_GEN5) static struct socfpga_system_manager *sysmgr_regs = (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS; +#endif /* * Populate the value for SYSMGR.FPGAINTF.MODULE based on pinmux setting. diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c index bfefafd..7fd922e 100644 --- a/drivers/fpga/socfpga.c +++ b/drivers/fpga/socfpga.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2012 Altera Corporation + * Copyright (C) 2012-2016 Altera Corporation * All rights reserved. * * SPDX-License-Identifier:BSD-3-Clause @@ -19,8 +19,10 @@ DECLARE_GLOBAL_DATA_PTR; static struct socfpga_fpga_manager *fpgamgr_regs = (struct socfpga_fpga_manager *)SOCFPGA_FPGAMGRREGS_ADDRESS; +#if defined(CONFIG_TARGET_SOCFPGA_GEN5) static struct socfpga_system_manager *sysmgr_regs = (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS; +#endif /* Set CD ratio */ static void fpgamgr_set_cd_ratio(unsigned long ratio) @@ -267,9 +269,10 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size) } /* Prior programming the FPGA, all bridges need to be shut off */ - +#if defined(CONFIG_TARGET_SOCFPGA_GEN5) /* Disable all signals from hps peripheral controller to fpga */ writel(0, &sysmgr_regs->fpgaintfgrp_module); +#endif /* Disable all signals from FPGA to HPS SDRAM */ #define SDR_CTRLGRP_FPGAPORTRST_ADDRESS0x5080 diff --git a/include/configs/socfpga_arria10_socdk.h b/include/configs/socfpga_arria10_socdk.h index 577f60f..15c7a28 100644 --- a/include/configs/socfpga_arria10_socdk.h +++ b/include/configs/socfpga_arria10_socdk.h @@ -1,5 +1,5 @@ /* - * Copyright (C) 2015 Altera Corporation + * Copyright (C) 2015-2016 Altera Corporation * * SPDX-License-Identifier:GPL-2.0 */ @@ -16,36 +16,67 @@ #define CONFIG_CMD_ASKENV #define CONFIG_CMD_BOOTZ -#define CONFIG_CMD_CACHE -#define CONFIG_CMD_DHCP #define CONFIG_CMD_EXT4 #define CONFIG_CMD_EXT4_WRITE -#define CONFIG_CMD_FAT -#define CONFIG_CMD_FS_GENERIC #define CONFIG_CMD_GREPENV -#define CONFIG_CMD_MMC #define CONFIG_CMD_PING -/* - * Memory configurations - */ -#define PHYS_SDRAM_1_SIZE 0x200 - /* Booting Linux */ -#define CONFIG_BOOTDELAY 3 #define CONFIG_BOOTFILE"zImage" #define CONFIG_BOOTARGS"console=ttyS0," __stringify(CONFIG_BAUDRATE) #define CONFIG_BOOTCOMMAND "run mmcload; run mmcboot" -#define CONFIG_LOADADDR0x0100 +#define CONFIG_LOADADDR0x8000 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR /* + * U-Boot general configurations + */ +/* Base address for .text section. */ +/* Ensure located start
[U-Boot] [PATCH 02/10] arm: socfpga: arria10: Added config option build for SPL
From: Tien Fong Chee These changes to ensure Arria10 SPL build success. Signed-off-by: Tien Fong Chee Cc: Marek Vasut Cc: Dinh Nguyen Cc: Chin Liang See Cc: Tien Fong --- arch/arm/Kconfig |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 220bb19..05ce8b8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -622,12 +622,12 @@ config ARCH_SNAPDRAGON config ARCH_SOCFPGA bool "Altera SOCFPGA family" select CPU_V7 - select SUPPORT_SPL if !TARGET_SOCFPGA_ARRIA10 + select SUPPORT_SPL select OF_CONTROL - select SPL_OF_CONTROL if !TARGET_SOCFPGA_ARRIA10 + select SPL_OF_CONTROL select DM - select DM_SPI_FLASH - select DM_SPI + select DM_SPI_FLASH if !TARGET_SOCFPGA_ARRIA10 + select DM_SPI if !TARGET_SOCFPGA_ARRIA10 config TARGET_CM_T43 bool "Support cm_t43" -- 1.7.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/10] arm: socfpga: arria10: Enhanced socfpga_arria10_defconfig to support SPL
From: Tien Fong Chee Enhanced defconfig file for Arria10 to enable SPL build and supporting device tree build for SDMMC. Signed-off-by: Tien Fong Chee Cc: Marek Vasut Cc: Dinh Nguyen Cc: Chin Liang See Cc: Tien Fong --- arch/arm/mach-socfpga/include/mach/boot0.h | 17 + configs/socfpga_arria10_defconfig | 18 +- 2 files changed, 30 insertions(+), 5 deletions(-) create mode 100644 arch/arm/mach-socfpga/include/mach/boot0.h diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h b/arch/arm/mach-socfpga/include/mach/boot0.h new file mode 100644 index 000..8052a0b --- /dev/null +++ b/arch/arm/mach-socfpga/include/mach/boot0.h @@ -0,0 +1,17 @@ +/* + * Copyright (C) 2016, Intel Corporation + * + * SPDX-License-Identifier:GPL-2.0 + */ + +#ifndef __BOOT0_H +#define __BOOT0_H + +#if (defined(CONFIG_ARCH_SOCFPGA) && defined(CONFIG_SPL_BUILD)) +/* BOOT0 header information */ +#define ARM_SOC_BOOT0_HOOK \ + .fill 12, 4, 0xdeadbeef +#else +#define ARM_SOC_BOOT0_HOOK +#endif +#endif /* __BOOT0_H */ diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 422261b..755bb66 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -3,14 +3,22 @@ CONFIG_ARCH_SOCFPGA=y CONFIG_TARGET_SOCFPGA_ARRIA10=y CONFIG_DM_GPIO=y CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y -CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk" +CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" +CONFIG_IDENT_STRING="socfpga_arria10" # CONFIG_CMD_IMLS is not set # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y CONFIG_DWAPB_GPIO=y -CONFIG_DM_ETH=y -CONFIG_ETH_DESIGNWARE=y CONFIG_SYS_NS16550=y -CONFIG_CADENCE_QSPI=y -CONFIG_DESIGNWARE_SPI=y CONFIG_DM_MMC=y +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_CMD_MMC=y +CONFIG_USE_TINY_PRINTF=y +CONFIG_SPL=y +CONFIG_SPL_DM=y +CONFIG_SPL_SIMPLE_BUS=y +CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_SERIAL_SUPPORT=y +CONFIG_SPL_OF_LIBFDT=y +CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y -- 1.7.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/10] ARM:dts: Added device tree for socfpga arria10 development kit sdmmc
From: Tien Fong Chee
This is initial version of device tree for the Intel socfpga arria10
development kit with sdmmc.
Signed-off-by: Tien Fong Chee
Cc: Marek Vasut
Cc: Dinh Nguyen
Cc: Chin Liang See
Cc: Tien Fong
---
arch/arm/dts/Makefile |3 +-
arch/arm/dts/socfpga_arria10.dtsi | 859 +++
arch/arm/dts/socfpga_arria10_handoff_sdmmc.dtsi | 473 +
arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts| 33 +
4 files changed, 1367 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/dts/socfpga_arria10.dtsi
create mode 100644 arch/arm/dts/socfpga_arria10_handoff_sdmmc.dtsi
create mode 100644 arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 032c5ae..72bbc67 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -131,7 +131,8 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=
\
socfpga_cyclone5_sockit.dtb \
socfpga_cyclone5_socrates.dtb \
socfpga_cyclone5_sr1500.dtb \
- socfpga_cyclone5_vining_fpga.dtb
+ socfpga_cyclone5_vining_fpga.dtb\
+ socfpga_arria10_socdk_sdmmc.dtb
dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb
dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb \
diff --git a/arch/arm/dts/socfpga_arria10.dtsi
b/arch/arm/dts/socfpga_arria10.dtsi
new file mode 100644
index 000..c54addb
--- /dev/null
+++ b/arch/arm/dts/socfpga_arria10.dtsi
@@ -0,0 +1,859 @@
+/*
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include "skeleton.dtsi"
+#include
+#include
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac1;
+ ethernet2 = &gmac2;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ timer0 = &timer0;
+ timer1 = &timer1;
+ timer2 = &timer2;
+ timer3 = &timer3;
+ spi0 = &spi0;
+ spi1 = &spi1;
+ };
+
+ memory {
+ name = "memory";
+ device_type = "memory";
+ reg = <0x0 0x4000>; /* 1GB */
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a9";
+ device_type = "cpu";
+ reg = <0>;
+ next-level-cache = <&L2>;
+ };
+ cpu@1 {
+ compatible = "arm,cortex-a9";
+ device_type = "cpu";
+ reg = <1>;
+ next-level-cache = <&L2>;
+ };
+ };
+
+ intc: intc@d000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0xd000 0x1000>,
+ <0xc100 0x100>;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ device_type = "soc";
+ interrupt-parent = <&intc>;
+ ranges;
+
+ amba {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pdma: pdma@ffda1000 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0xffda1000 0x1000>;
+ interrupts = <0 83 IRQ_TYPE_LEVEL_HIGH>,
+<0 84 IRQ_TYPE_LEVEL_HIGH>,
+<0 85 IRQ_TYPE_LEVEL_HIGH>,
+<0 86 IRQ_TYPE_LEVEL_HIGH>,
+<0 87 IRQ_TYPE_LEVEL_HIGH>,
+<0 88 IRQ_TYPE_LEVEL_HIGH>,
+<0 89 IRQ_TYPE_LEVEL_HIGH>,
+<0 90 IRQ_TYPE_LEVEL_HIGH>,
+<0 91 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ clocks = <&l4_main_clk>;
+ clock-names = "apb_pclk";
+ };
+ };
+
+ clkmgr@ffd04000 {
+ compatible = "altr,clk-mgr";
+ reg = <0xffd04000 0x1000>;
+ reg-names = "soc_clock_manager_OCP_SLV";
+
+ c
Re: [U-Boot] [PATCH v2 23/23] sunxi: A64: add 32-bit SPL support
On Mon, Dec 05, 2016 at 01:52:30AM +, Andre Przywara wrote: > When compiling the SPL for the Allwinner A64 in AArch64 mode, we can't > use the more compact Thumb2 encoding, which only exists for AArch32 > code. This makes the SPL rather big, up to a point where any code > additions or even a different compiler may easily exceed the 32KB limit > that the Allwinner BROM imposes. > Introduce a separate, mostly generic sun50i-a64 configuration, which > defines the CPU_V7 symbol and thus will create a 32-bit binary using > the memory-saving Thumb2 encoding. "mostly generic". Where do you draw the line? How do you deal with a board that would use a different UART? a different MMC? different memory configuration.? This looks like it's not generic at all, it's just a configuration for the Pine64. 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 v2 12/23] sunxi: provide default DRAM config for sun50i in Kconfig
Hi, On 06/12/16 10:56, Maxime Ripard wrote: > On Mon, Dec 05, 2016 at 01:52:19AM +, Andre Przywara wrote: >> To avoid enumerating the very same DRAM values in defconfig files >> for each and every Allwinner A64 board out there, let's put some sane >> default values in the Kconfig file. >> Boards with different needs can override them at any time. > > Did you check other boards to see what their values were before > calling it a default? I sampled all the boards (two ;-) I have access to and got a 100% coverage ;-) As far as I know, this 672 MHz seems to be an Allwinner recommendation, though it needs to be worked out how stable this is under load. I have no idea if the ZQ value is similarly common. If you have any other data, I am all ears and happy to use a different safe default if this is the intention. But we could use a "most common value" approach here to avoid pointless defconfig entries with the same value for lots of boards, so even if there are board with can't do 672 MHz, for instance, we still put it in Kconfig and let that one board override it. Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/23] sunxi: A64: use H3 DRAM initialization code for A64
On Mon, Dec 05, 2016 at 01:52:22AM +, Andre Przywara wrote:
> From: Jens Kuske
>
> The A64 DRAM controller is very similar to the H3 one,
> so the code can be reused with some small changes.
> [Andre: fixed up typo, merged in fixes from Jens]
>
> Signed-off-by: Jens Kuske
> Signed-off-by: Andre Przywara
> ---
> arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 1 +
> arch/arm/include/asm/arch-sunxi/dram.h | 2 +-
> arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h | 10 +-
> arch/arm/mach-sunxi/Makefile| 1 +
> arch/arm/mach-sunxi/clock_sun6i.c | 2 +-
> arch/arm/mach-sunxi/dram_sun8i_h3.c | 139
> +++-
> 6 files changed, 123 insertions(+), 32 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> index be9fcfd..3f87672 100644
> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
> @@ -322,6 +322,7 @@ struct sunxi_ccm_reg {
> #define CCM_DRAMCLK_CFG_DIV0_MASK(0xf << 8)
> #define CCM_DRAMCLK_CFG_SRC_PLL5 (0x0 << 20)
> #define CCM_DRAMCLK_CFG_SRC_PLL6x2 (0x1 << 20)
> +#define CCM_DRAMCLK_CFG_SRC_PLL11(0x1 << 20) /* A64 only */
> #define CCM_DRAMCLK_CFG_SRC_MASK (0x3 << 20)
> #define CCM_DRAMCLK_CFG_UPD (0x1 << 16)
> #define CCM_DRAMCLK_CFG_RST (0x1 << 31)
> diff --git a/arch/arm/include/asm/arch-sunxi/dram.h
> b/arch/arm/include/asm/arch-sunxi/dram.h
> index e0be744..53e6d47 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram.h
> @@ -24,7 +24,7 @@
> #include
> #elif defined(CONFIG_MACH_SUN8I_A83T)
> #include
> -#elif defined(CONFIG_MACH_SUN8I_H3)
> +#elif defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
> #include
> #elif defined(CONFIG_MACH_SUN9I)
> #include
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> index 867fd12..b0e5d93 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> @@ -15,7 +15,8 @@
>
> struct sunxi_mctl_com_reg {
> u32 cr; /* 0x00 control register */
> - u8 res0[0xc]; /* 0x04 */
> + u8 res0[0x8]; /* 0x04 */
> + u32 tmr;/* 0x0c (A64 only) */
#ifdef?
> u32 mcr[16][2]; /* 0x10 */
> u32 bwcr; /* 0x90 bandwidth control register */
> u32 maer; /* 0x94 master enable register */
> @@ -32,7 +33,9 @@ struct sunxi_mctl_com_reg {
> u32 swoffr; /* 0xc4 */
> u8 res2[0x8]; /* 0xc8 */
> u32 cccr; /* 0xd0 */
> - u8 res3[0x72c]; /* 0xd4 */
> + u8 res3[0x54]; /* 0xd4 */
> + u32 mdfs_bwlr[3]; /* 0x128 (A64 only) */
> + u8 res4[0x6cc]; /* 0x134 */
Ditto.
> u32 protect;/* 0x800 */
> };
>
> @@ -81,7 +84,8 @@ struct sunxi_mctl_ctl_reg {
> u32 rfshtmg;/* 0x90 refresh timing */
> u32 rfshctl1; /* 0x94 */
> u32 pwrtmg; /* 0x98 */
> - u8 res3[0x20]; /* 0x9c */
> + u8 res3[0x1c]; /* 0x9c */
> + u32 vtfcr; /* 0xb8 (A64 only) */
Ditto
> u32 dqsgmr; /* 0xbc */
> u32 dtcr; /* 0xc0 */
> u32 dtar[4];/* 0xc4 */
> diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
> index e73114e..7daba11 100644
> --- a/arch/arm/mach-sunxi/Makefile
> +++ b/arch/arm/mach-sunxi/Makefile
> @@ -50,4 +50,5 @@ obj-$(CONFIG_MACH_SUN8I_A33)+= dram_sun8i_a33.o
> obj-$(CONFIG_MACH_SUN8I_A83T)+= dram_sun8i_a83t.o
> obj-$(CONFIG_MACH_SUN8I_H3) += dram_sun8i_h3.o
> obj-$(CONFIG_MACH_SUN9I) += dram_sun9i.o
> +obj-$(CONFIG_MACH_SUN50I)+= dram_sun8i_h3.o
> endif
> diff --git a/arch/arm/mach-sunxi/clock_sun6i.c
> b/arch/arm/mach-sunxi/clock_sun6i.c
> index 80cfc0b..99f515d 100644
> --- a/arch/arm/mach-sunxi/clock_sun6i.c
> +++ b/arch/arm/mach-sunxi/clock_sun6i.c
> @@ -217,7 +217,7 @@ done:
> }
> #endif
>
> -#ifdef CONFIG_MACH_SUN8I_A33
> +#if defined(CONFIG_MACH_SUN8I_A33) || defined(CONFIG_MACH_SUN50I)
> void clock_set_pll11(unsigned int clk, bool sigma_delta_enable)
> {
> struct sunxi_ccm_reg * const ccm =
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c
> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> index 1647d76..2dc2071 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> @@ -32,30 +32,6 @@ static inline int ns_to_t(int nanoseconds)
> return DIV_ROUND_UP(ctrl_freq * nanoseconds, 1000);
> }
>
> -static u32 bin_to_mgray(int val)
> -{
> - static const u8 lookup_table[32] = {
> - 0x00, 0x01, 0x02, 0x03, 0x06, 0x07, 0x04, 0x05,
> - 0x0c, 0x0d, 0x0e, 0x0f, 0x0a
Re: [U-Boot] [PATCH v2 14/23] sunxi: H3: add DRAM controller single bit delay support
On Mon, Dec 05, 2016 at 01:52:21AM +, Andre Przywara wrote:
> From: Jens Kuske
>
> Instead of setting the delay for whole bytes allow setting
> it for each individual bit. Also add support for
> address/command lane delays.
>
> Signed-off-by: Jens Kuske
> Signed-off-by: Andre Przywara
> ---
> arch/arm/mach-sunxi/dram_sun8i_h3.c | 54
> ++---
> 1 file changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c
> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> index 3dd6803..1647d76 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> @@ -16,12 +16,13 @@
> #include
>
> struct dram_para {
> - u32 read_delays;
> - u32 write_delays;
> u16 page_size;
> u8 bus_width;
> u8 dual_rank;
> u8 row_bits;
> + const u8 dx_read_delays[4][11];
> + const u8 dx_write_delays[4][11];
> + const u8 ac_delays[31];
> };
Some documentation on what is the expected format and what it
corresponds to would be welcome.
>
> static inline int ns_to_t(int nanoseconds)
> @@ -64,34 +65,25 @@ static void mctl_phy_init(u32 val)
> mctl_await_completion(&mctl_ctl->pgsr[0], PGSR_INIT_DONE, 0x1);
> }
>
> -static void mctl_dq_delay(u32 read, u32 write)
> +static void mctl_set_bit_delays(struct dram_para *para)
> {
> struct sunxi_mctl_ctl_reg * const mctl_ctl =
> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> int i, j;
> - u32 val;
> -
> - for (i = 0; i < 4; i++) {
> - val = DXBDLR_WRITE_DELAY((write >> (i * 4)) & 0xf) |
> - DXBDLR_READ_DELAY(((read >> (i * 4)) & 0xf) * 2);
> -
> - for (j = DXBDLR_DQ(0); j <= DXBDLR_DM; j++)
> - writel(val, &mctl_ctl->dx[i].bdlr[j]);
> - }
>
> clrbits_le32(&mctl_ctl->pgcr[0], 1 << 26);
>
> - for (i = 0; i < 4; i++) {
> - val = DXBDLR_WRITE_DELAY((write >> (16 + i * 4)) & 0xf) |
> - DXBDLR_READ_DELAY((read >> (16 + i * 4)) & 0xf);
> + for (i = 0; i < 4; i++)
> + for (j = 0; j < 11; j++)
> + writel(DXBDLR_WRITE_DELAY(para->dx_write_delays[i][j]) |
> +DXBDLR_READ_DELAY(para->dx_read_delays[i][j]),
> +&mctl_ctl->dx[i].bdlr[j]);
>
> - writel(val, &mctl_ctl->dx[i].bdlr[DXBDLR_DQS]);
> - writel(val, &mctl_ctl->dx[i].bdlr[DXBDLR_DQSN]);
> - }
> + for (i = 0; i < 31; i++)
> + writel(ACBDLR_WRITE_DELAY(para->ac_delays[i]),
> +&mctl_ctl->acbdlr[i]);
>
> setbits_le32(&mctl_ctl->pgcr[0], 1 << 26);
> -
> - udelay(1);
> }
>
> static void mctl_set_master_priority(void)
> @@ -372,11 +364,8 @@ static int mctl_channel_init(struct dram_para *para)
> clrsetbits_le32(&mctl_ctl->dtcr, 0xf << 24,
> (para->dual_rank ? 0x3 : 0x1) << 24);
>
> -
> - if (para->read_delays || para->write_delays) {
> - mctl_dq_delay(para->read_delays, para->write_delays);
> - udelay(50);
> - }
> + mctl_set_bit_delays(para);
> + udelay(50);
>
> mctl_zq_calibration(para);
>
> @@ -458,12 +447,23 @@ unsigned long sunxi_dram_init(void)
> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>
> struct dram_para para = {
> - .read_delays = 0x7979, /* dram_tpr12 */
> - .write_delays = 0x6aaa, /* dram_tpr11 */
> .dual_rank = 0,
> .bus_width = 32,
> .row_bits = 15,
> .page_size = 4096,
> +
> + .dx_read_delays = {{ 18, 18, 18, 18, 18, 18, 18, 18, 18, 0,
> 0 },
> + { 14, 14, 14, 14, 14, 14, 14, 14, 14, 0,
> 0 },
> + { 18, 18, 18, 18, 18, 18, 18, 18, 18, 0,
> 0 },
> + { 14, 14, 14, 14, 14, 14, 14, 14, 14, 0,
> 0 }},
> + .dx_write_delays = {{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 10,
> 10 },
> + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 10,
> 10 },
> + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 10,
> 10 },
> + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 6,
> 6 }},
> + .ac_delays = { 0, 0, 0, 0, 0, 0, 0, 0,
> + 0, 0, 0, 0, 0, 0, 0, 0,
> + 0, 0, 0, 0, 0, 0, 0, 0,
> + 0, 0, 0, 0, 0, 0, 0 },
You're mixing tabs and spaces for the indentation, and the tab before
that bracket looks useless.
Thanks,
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:
Re: [U-Boot] [PATCH v2 13/23] sunxi: H3: add and rename some DRAM contoller registers
On Mon, Dec 05, 2016 at 01:52:20AM +, Andre Przywara wrote:
> From: Jens Kuske
>
> The IOCR registers got renamed to BDLR to match the public
> documentation of similar controllers.
It looks like there's a lot more to it.
>
> Signed-off-by: Jens Kuske
> Signed-off-by: Andre Przywara
> ---
> arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h | 43
> ++---
> arch/arm/mach-sunxi/dram_sun8i_h3.c | 34 +--
> 2 files changed, 41 insertions(+), 36 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> index d0f2b8a..867fd12 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> @@ -81,7 +81,7 @@ struct sunxi_mctl_ctl_reg {
> u32 rfshtmg;/* 0x90 refresh timing */
> u32 rfshctl1; /* 0x94 */
> u32 pwrtmg; /* 0x98 */
> - u8 res3[0x20]; /* 0x9c */
> + u8 res3[0x20]; /* 0x9c */
Spurious change?
Thanks,
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 v2 12/23] sunxi: provide default DRAM config for sun50i in Kconfig
On Mon, Dec 05, 2016 at 01:52:19AM +, Andre Przywara wrote: > To avoid enumerating the very same DRAM values in defconfig files > for each and every Allwinner A64 board out there, let's put some sane > default values in the Kconfig file. > Boards with different needs can override them at any time. Did you check other boards to see what their values were before calling it a default? Thanks, 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 v2 11/23] sunxi: A64: do an RMR switch if started in AArch32 mode
On Mon, Dec 05, 2016 at 10:41:27AM +, Andre Przywara wrote:
> Hi Simon,
>
> thanks a lot for looking at this!
>
> On 05/12/16 06:25, Simon Glass wrote:
> > Hi Andre,
> >
> > On 4 December 2016 at 18:52, Andre Przywara wrote:
> >> The Allwinner A64 SoC starts execution in AArch32 mode, and both
> >> the boot ROM and Allwinner's boot0 keep running in this mode.
> >> So U-Boot gets entered in 32-bit, although we want it to run in AArch64.
> >>
> >> By using a "magic" instruction, which happens to be an almost-NOP in
> >> AArch64 and a branch in AArch32, we differentiate between being
> >> entered in 64-bit or 32-bit mode.
> >> If in 64-bit mode, we proceed with the branch to reset, but in 32-bit
> >> mode we trigger an RMR write to bring the core into AArch64/EL3 and
> >> re-enter U-Boot at CONFIG_SYS_TEXT_BASE.
> >> This allows a 64-bit U-Boot to be both entered in 32 and 64-bit mode,
> >> so we can use the same start code for the SPL and the U-Boot proper.
> >>
> >> We use the existing custom header (boot0.h) functionality, but restrict
> >> the existing boot0 header reservation to the non-SPL build now. A SPL
> >> wouldn't need such header anyway. This allows to have both options
> >> defined and lets us use one for the SPL and the other for U-Boot proper.
> >>
> >> Signed-off-by: Andre Przywara
> >> ---
> >> arch/arm/include/asm/arch-sunxi/boot0.h | 27 +++
> >> board/sunxi/Kconfig | 5 +
> >> 2 files changed, 32 insertions(+)
> >
> > Reviewed-by: Simon Glass
> >
> >>
> >> diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h
> >> b/arch/arm/include/asm/arch-sunxi/boot0.h
> >> index 6a13db5..7799a03 100644
> >> --- a/arch/arm/include/asm/arch-sunxi/boot0.h
> >> +++ b/arch/arm/include/asm/arch-sunxi/boot0.h
> >> @@ -4,6 +4,33 @@
> >> * SPDX-License-Identifier:GPL-2.0+
> >> */
> >>
> >> +#if defined(CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER) &&
> >> !defined(CONFIG_SPL_BUILD)
> >> /* reserve space for BOOT0 header information */
> >> b reset
> >> .space 1532
> >> +#elif defined(CONFIG_ARM_BOOT_HOOK_RMR)
> >> +/* switch into AArch64 if needed */
> >> + tst x0, x0 // this is "b #0x84" in ARM
> >> + b reset
> >> + .space 0x7c
> >> + .word 0xe59f1024 // ldr r1, [pc, #36] ; 0x17a0
> >> + .word 0xe59f0024 // ldr r0, [pc, #36] ;
> >> CONFIG_*_TEXT_BASE
> >> + .word 0xe581 // str r0, [r1]
> >> + .word 0xf57ff04f // dsb sy
> >> + .word 0xf57ff06f // isb sy
> >> + .word 0xee1c0f50 // mrc 15, 0, r0, cr12, cr0, {2} ; RMR
> >> + .word 0xe383 // orr r0, r0, #3
> >> + .word 0xee0c0f50 // mcr 15, 0, r0, cr12, cr0, {2} ; RMR
> >> + .word 0xf57ff06f // isb sy
> >> + .word 0xe320f003 // wfi
> >> + .word 0xeafd // b @wfi
> >> + .word 0x017000a0 // writeable RVBAR mapping address
> >
> > How come you cannot use the assembler here?
>
> Because this is ARM code, whereas this file is included in an AArch64
> build. In contrast to x86 the AArch64 toolchain does not support both
> bitnesses in one build, mostly because the two architectures are really
> different.
>
> The actual reason for this exercise is that the Allwinner boot ROM
> enters the payload in AArch32 mode, but we want to compile and run the
> SPL in AArch64. So we need some small ARM(32) stub to enter AArch64.
>
> Running the whole SPL in 32-bit is the other option which the later
> patches enable, but I didn't want to call some 32-bit ARM
> (cross-)compiler just for this handful of instructions in this case here.
A comment stating that, and how to regenerate that part from a actual
assembly source would be great.
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 v2 10/23] sunxi: introduce extra config option for boot0 header
On Mon, Dec 05, 2016 at 01:52:17AM +, Andre Przywara wrote: > The ENABLE_ARM_SOC_BOOT0_HOOK option is a generic option shared with > other boards. To allow alternative code to be inserted, we create > another, now function specific config symbol on top of it to simplify > later additions. No functional change at this time. > > Signed-off-by: Andre Przywara Acked-by: Maxime Ripard Thanks, 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 v2 06/23] SPL: make struct spl_image 64-bit safe
On Mon, Dec 05, 2016 at 01:52:13AM +, Andre Przywara wrote: > Since entry_point and load_addr are addresses, they should be > represented as longs to cover the whole address space and to avoid > warning when compiling the SPL in 64-bit. > Also adjust debug prints to add the 'l' specifier, where needed. > > Signed-off-by: Andre Przywara > Reviewed-by: Alexander Graf Acked-by: Maxime Ripard Thanks, 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 v3 11/11] spi: cadence_qspi: Support specifying the sample edge used
Hi Marek, On 05 December 2016 13:31, Marek Vasut wrote: > On 12/05/2016 11:46 AM, Phil Edworthy wrote: > > On 05 December 2016 10:42, Jagan Teki wrote: > >> On Mon, Dec 5, 2016 at 11:31 AM, Phil Edworthy > >> wrote: > >>> On 05 December 2016 10:26, Jagan Teki wrote: > On Mon, Dec 5, 2016 at 11:09 AM, Phil Edworthy > wrote: > > On 02 December 2016 14:23, Jagan Teki wrote: > >> On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy > >> wrote: > >>> Introduce a new DT property to specify whether the QSPI Controller > >>> samples the data on a rising edge. The default is falling edge. > >>> Some versions of the QSPI Controller do not implement this bit, in > >>> which case the property should be omitted. > >>> > >>> Signed-off-by: Phil Edworthy > >>> --- > >>> v3: > >>> - Patch split so this one only has code related to the subject. > >>> - Commit message updated. > >>> v2: > >>> - Change name of DT prop and provide details of what it does. > >>> Whilst at it, move the code to read the "sram-size" property > >>> into the other code that reads properties from the node, rather > >>> than the SF subnode. > >>> > >>> Also change the code to use a bool for the bypass arg. > >>> --- > >>> doc/device-tree-bindings/spi/spi-cadence.txt | 2 ++ > >>> drivers/spi/cadence_qspi.c | 10 +++--- > >>> drivers/spi/cadence_qspi.h | 3 ++- > >>> drivers/spi/cadence_qspi_apb.c | 8 +++- > >>> 4 files changed, 18 insertions(+), 5 deletions(-) > >>> > >>> diff --git a/doc/device-tree-bindings/spi/spi-cadence.txt > >>> b/doc/device- > >> tree- > >> bindings/spi/spi-cadence.txt > >>> index c1e2233..94c800b 100644 > >>> --- a/doc/device-tree-bindings/spi/spi-cadence.txt > >>> +++ b/doc/device-tree-bindings/spi/spi-cadence.txt > >>> @@ -26,3 +26,5 @@ connected flash properties > >>> select (n_ss_out). > >>> - tslch-ns : Delay in master reference clocks between > >>> setting > >>> n_ss_out low and first bit transfer > >>> +- sample-edge-rising : Data outputs from flash memory will be > sampled > >> on > >> the > >>> + rising edge. Default is falling edge. > >> > >> Code look reasonable, but how Linux handling this with the same dt > >> property, any idea? I couldn't find it either. > > The Linux driver does not yet have this property. Is there a policy to > > add > new > > props to Linux first? > > If the same/equal code used in Linux better to have the same property > instead of another name used in U-boot? > >>> Of course, but I cannot see this in Linux: > >>> https://git.kernel.org/cgit/linux/kernel/git/next/linux- > >> next.git/tree/Documentation/devicetree/bindings/spi/spi-cadence.txt > >> > >> Yeah, I saw this. Do you have any idea how Linux handling this sample edge? > > The same way U-Boot currently handles it, i.e. it does nothing with this. > Intel/Altera > > (Chin Liang) said that they do not have this bit in their version of the > > Cadence > QSPI > > Controller. > > > > We are using a later version that has had this bit added. > > You were looking at the wrong bindings: > https://git.kernel.org/cgit/linux/kernel/git/next/linux- > next.git/tree/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt Thanks for pointing that out! > but yes, Linux does not do support the data edge toggling. I think there > was another QSPI patch in Linux which tried adding such property, so > check linux-mtd for it. Generic one would be great. I had a search around, but couldn't find anything. > And no, there is no policy for pushing new props to linux first. New DT > props should ideally get approved via devicetree@vger though, but that's > about it. Also, while I tried backporting the Linux CQSPI driver to > U-Boot, but unfortunately, it turned out to be extremely difficult due > significant differences between the Linux and U-Boot SPI NOR framework. OK, thanks for the information. Thanks Phil ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] arm64: mvebu: Add bubt command for flash image burn
Hi Kosta,
On 06.12.2016 10:06, Kostya Porotchkin wrote:
+int is_mmc_active(void)
+{
+ return 1;
+}
+#else /* CONFIG_DM_MMC */
+#define mmc_burn_image 0
+#define mmc_read_file 0
+#define is_mmc_active 0
+#endif /* CONFIG_DM_MMC */
Please use empty functions instead.
[Konstantin Porotchkin]
Do you mean defining it in this way?
#define mmc_burn_image(a) 0
Or like below?
int mmc_burn_image(size_t image_size)
{
return -1;
}
The latter please. Perhaps its also possible to return some
decent error code in this case (ENODEV?) so that the
calling code can handle this case even better or report
this clearer to the user.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/6] arm64: mvebu: Add bubt command for flash image burn
Hi, Stefan, > -Original Message- > From: Stefan Roese [mailto:s...@denx.de] > Sent: Tuesday, December 06, 2016 08:22 > To: Kostya Porotchkin; u-boot@lists.denx.de > Cc: Nadav Haklai; Neta Zur Hershkovits; Omri Itach; Igal Liberman; Haim > Boot; Hanna Hawa > Subject: Re: [PATCH v2 2/6] arm64: mvebu: Add bubt command for flash > image burn > > On 04.12.2016 17:12, kos...@marvell.com wrote: > > From: Konstantin Porotchkin > > > > Add support for mvebu bubt command for flash image load, check and > > burn on boot device. > > > > Changes for v2: > > - Add "bubt" documentation > > - Fix code syntax > > > > Signed-off-by: Konstantin Porotchkin > > Cc: Stefan Roese > > Cc: Nadav Haklai > > Cc: Neta Zur Hershkovits > > Cc: Omri Itach > > Cc: Igal Liberman > > Cc: Haim Boot > > Cc: Hanna Hawa > > --- > > Again, please move the patch version history. > > It seems that you missed to address most of my last review comments. > I've added them again below. Please either address them or give me a > short notice why not. Thanks. > > > arch/arm/mach-mvebu/Kconfig | 34 +++ > > cmd/Kconfig | 3 + > > cmd/Makefile| 2 + > > cmd/mvebu/Kconfig | 10 + > > cmd/mvebu/Makefile | 8 + > > cmd/mvebu/bubt.c| 726 > > > doc/mvebu/cmd/bubt.txt | 64 > > 7 files changed, 847 insertions(+) > > create mode 100644 cmd/mvebu/Kconfig > > create mode 100644 cmd/mvebu/Makefile create mode 100644 > > cmd/mvebu/bubt.c create mode 100644 doc/mvebu/cmd/bubt.txt > > > > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig > > index 7248fd7..dba5c98 100644 > > --- a/arch/arm/mach-mvebu/Kconfig > > +++ b/arch/arm/mach-mvebu/Kconfig > > @@ -99,6 +99,40 @@ config TARGET_THEADORABLE > > > > endchoice > > > > +choice > > + prompt "Flash for image" > > + default MVEBU_SPI_BOOT > > + > > +config MVEBU_NAND_BOOT > > + bool "NAND flash boot" > > + depends on NAND_PXA3XX > > + help > > + Enable boot from NAND flash. > > + Use NAND flash as a target for "bubt" command > > + > > +config MVEBU_SPI_BOOT > > + bool "SPI flash boot" > > + depends on SPI_FLASH > > + help > > + Enable boot from SPI flash. > > + Use SPI flash as a target for "bubt" command > > + > > +config MVEBU_MMC_BOOT > > + bool "eMMC flash boot" > > + depends on MVEBU_MMC > > + help > > + Enable boot from eMMC boot partition > > + Use eMMC/SD device as a target for "bubt" command > > + > > +endchoice > > + > > +config MVEBU_UBOOT_DFLT_NAME > > + string "Default image name for bubt command" > > + default "flash-image.bin" > > + help > > + This option should contain a default file name to be used with > > + MVEBU "bubt" command if the source file name is omitted > > + > > Again my question on this location of these Kconfig options. Wouldn't it > be better, to move all Kconfig option into cmd/mvebu/Kconfig instead of > having most of them in the mach-mvebu file? > > > config SYS_BOARD > > default "clearfog" if TARGET_CLEARFOG > > default "mvebu_db-88f3720" if TARGET_MVEBU_DB_88F3720 diff --git > > a/cmd/Kconfig b/cmd/Kconfig index b16c603..b38d285 100644 > > --- a/cmd/Kconfig > > +++ b/cmd/Kconfig > > @@ -632,6 +632,9 @@ config CMD_QFW > > This provides access to the QEMU firmware interface. The main > > feature is to allow easy loading of files passed to qemu-system > > via -kernel / -initrd > > + > > +source "cmd/mvebu/Kconfig" > > + > > endmenu > > > > config CMD_BOOTSTAGE > > diff --git a/cmd/Makefile b/cmd/Makefile index 9c9a9d1..34bc544 100644 > > --- a/cmd/Makefile > > +++ b/cmd/Makefile > > @@ -163,3 +163,5 @@ obj-$(CONFIG_CMD_BLOB) += blob.o > > > > # core command > > obj-y += nvedit.o > > + > > +obj-$(CONFIG_ARCH_MVEBU) += mvebu/ > > diff --git a/cmd/mvebu/Kconfig b/cmd/mvebu/Kconfig new file mode > > 100644 index 000..e7fbd20 > > --- /dev/null > > +++ b/cmd/mvebu/Kconfig > > @@ -0,0 +1,10 @@ > > +menu "MVEBU commands" > > +depends on ARCH_MVEBU > > + > > +config CMD_MVEBU_BUBT > > + bool "bubt" > > + default n > > + help > > + bubt - Burn a u-boot image to flash > > + > > +endmenu > > diff --git a/cmd/mvebu/Makefile b/cmd/mvebu/Makefile new file mode > > 100644 index 000..03de53e > > --- /dev/null > > +++ b/cmd/mvebu/Makefile > > @@ -0,0 +1,8 @@ > > +# > > +# Copyright (C) 2016 Marvell International Ltd. > > +# > > +# SPDX-License-Identifier: GPL-2.0 > > +# https://spdx.org/licenses > > + > > + > > +obj-$(CONFIG_CMD_MVEBU_BUBT) += bubt.o > > diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c new file mode 100644 > > index 000..1aee728 > > --- /dev/null > > +++ b/cmd/mvebu/bubt.c > > @@ -0,0 +1,726 @@ > > +/* > > + * Copyright (C) 2016 Marvell International Ltd. > > + * > > + * SPDX-License-Identifier:GPL-2.0 > > + * https://spdx.org/licenses > > + */ > > + > > +#include > > +#include > > +#inclu
Re: [U-Boot] [PATCH v2 1/6] arm64: mvebu: Modify the A8K SPI and I2C config in DTS
Hi Kosta, On 06.12.2016 09:26, Kostya Porotchkin wrote: -Original Message- From: Stefan Roese [mailto:s...@denx.de] Sent: Tuesday, December 06, 2016 08:13 To: Kostya Porotchkin; u-boot@lists.denx.de Cc: Nadav Haklai; Neta Zur Hershkovits; Omri Itach; Igal Liberman; Haim Boot; Hanna Hawa Subject: Re: [PATCH v2 1/6] arm64: mvebu: Modify the A8K SPI and I2C config in DTS Hi Kosta, On 04.12.2016 17:12, kos...@marvell.com wrote: From: Konstantin Porotchkin Align the Armada-8040-db and Armada-7040-db SPI and I2C DTS settings with latest DB settings: - 8040-db: disable i2c0 and spi0 on AP (MPPs are reserved for SDIO) - 8040-db: disable cps_i2c0 on CP1 - 8040-db: enable spi1 on CP1 (the new location of the boot flash) The spi1 on CP1 is aliased as spi0 since this is the way the driver enumerates it. Changes for v2: - 7040-db: remove i2c0 and spi0 entries from AP (MPPs are reserved for SDIO) Signed-off-by: Konstantin Porotchkin Cc: Stefan Roese Cc: Nadav Haklai Cc: Neta Zur Hershkovits Cc: Omri Itach Cc: Igal Liberman Cc: Haim Boot Cc: Hanna Hawa --- Please move the patch version history below this "---" line. By doing this, the history will not be added to the git repository (where it does not really belong). Please do this generally for all your patches please. [Konstantin Porotchkin] As far as I understand the only way to do so is to edit the output patch file produced by "git format-patch". If I put the change log into my commit message, it always added before the comment line. Is it the right way of handling this kind of comments? Yes, this is one way of handling this. You can also use the patman tool (tools/patman/*) to handle your patches. Its especially helpful when you have to deal with bigger patchsets that likely will undergo multiple versions. I suggest you take a look at the README here as well: tools/patman/README But for now (this current patchset) I suggest to manually edit the patches. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] arm64: mvebu: Modify the A8K SPI and I2C config in DTS
Hi, Stefan,
> -Original Message-
> From: Stefan Roese [mailto:s...@denx.de]
> Sent: Tuesday, December 06, 2016 08:13
> To: Kostya Porotchkin; u-boot@lists.denx.de
> Cc: Nadav Haklai; Neta Zur Hershkovits; Omri Itach; Igal Liberman; Haim
> Boot; Hanna Hawa
> Subject: Re: [PATCH v2 1/6] arm64: mvebu: Modify the A8K SPI and I2C
> config in DTS
>
> Hi Kosta,
>
> On 04.12.2016 17:12, kos...@marvell.com wrote:
> > From: Konstantin Porotchkin
> >
> > Align the Armada-8040-db and Armada-7040-db SPI and I2C DTS settings
> > with latest DB settings:
> > - 8040-db: disable i2c0 and spi0 on AP (MPPs are reserved for SDIO)
> > - 8040-db: disable cps_i2c0 on CP1
> > - 8040-db: enable spi1 on CP1 (the new location of the boot flash)
> > The spi1 on CP1 is aliased as spi0 since this is the way
> > the driver enumerates it.
> >
> > Changes for v2:
> > - 7040-db: remove i2c0 and spi0 entries from AP (MPPs are reserved for
> > SDIO)
> >
> > Signed-off-by: Konstantin Porotchkin
> > Cc: Stefan Roese
> > Cc: Nadav Haklai
> > Cc: Neta Zur Hershkovits
> > Cc: Omri Itach
> > Cc: Igal Liberman
> > Cc: Haim Boot
> > Cc: Hanna Hawa
> > ---
>
> Please move the patch version history below this "---" line. By doing
> this, the history will not be added to the git repository (where it does
> not really belong). Please do this generally for all your patches
> please.
[Konstantin Porotchkin]
As far as I understand the only way to do so is to edit the output patch file
produced by "git format-patch".
If I put the change log into my commit message, it always added before the
comment line.
Is it the right way of handling this kind of comments?
>
> Other than this:
>
> Reviewed-by: Stefan Roese
>
> > arch/arm/dts/armada-7040-db.dts | 32 --
> > arch/arm/dts/armada-8040-db.dts | 60
> > +
> > 2 files changed, 25 insertions(+), 67 deletions(-)
> >
> > diff --git a/arch/arm/dts/armada-7040-db.dts
> > b/arch/arm/dts/armada-7040-db.dts index b8fe5a9..1e4d676 100644
> > --- a/arch/arm/dts/armada-7040-db.dts
> > +++ b/arch/arm/dts/armada-7040-db.dts
> > @@ -66,38 +66,6 @@
> > };
> > };
> >
> > -&i2c0 {
> > - status = "okay";
> > - clock-frequency = <10>;
> > -};
> > -
> > -&spi0 {
> > - status = "okay";
> > -
> > - spi-flash@0 {
> > - #address-cells = <1>;
> > - #size-cells = <1>;
> > - compatible = "jedec,spi-nor";
> > - reg = <0>;
> > - spi-max-frequency = <1000>;
> > -
> > - partitions {
> > - compatible = "fixed-partitions";
> > - #address-cells = <1>;
> > - #size-cells = <1>;
> > -
> > - partition@0 {
> > - label = "U-Boot";
> > - reg = <0 0x20>;
> > - };
> > - partition@40 {
> > - label = "Filesystem";
> > - reg = <0x20 0xce>;
> > - };
> > - };
> > - };
> > -};
> > -
> > &uart0 {
> > status = "okay";
> > };
> > diff --git a/arch/arm/dts/armada-8040-db.dts
> > b/arch/arm/dts/armada-8040-db.dts index 7fb674b..8a1 100644
> > --- a/arch/arm/dts/armada-8040-db.dts
> > +++ b/arch/arm/dts/armada-8040-db.dts
> > @@ -57,7 +57,7 @@
> >
> > aliases {
> > i2c0 = &cpm_i2c0;
> > - spi0 = &spi0;
> > + spi0 = &cps_spi1;
> > };
> >
> > memory@ {
> > @@ -66,38 +66,6 @@
> > };
> > };
> >
> > -&i2c0 {
> > - status = "okay";
> > - clock-frequency = <10>;
> > -};
> > -
> > -&spi0 {
> > - status = "okay";
> > -
> > - spi-flash@0 {
> > - #address-cells = <1>;
> > - #size-cells = <1>;
> > - compatible = "jedec,spi-nor";
> > - reg = <0>;
> > - spi-max-frequency = <1000>;
> > -
> > - partitions {
> > - compatible = "fixed-partitions";
> > - #address-cells = <1>;
> > - #size-cells = <1>;
> > -
> > - partition@0 {
> > - label = "U-Boot";
> > - reg = <0 0x20>;
> > - };
> > - partition@40 {
> > - label = "Filesystem";
> > - reg = <0x20 0xce>;
> > - };
> > - };
> > - };
> > -};
> > -
> > /* Accessible over the mini-USB CON9 connector on the main board */
> > &uart0 {
> > status = "okay";
> > @@ -134,9 +102,31 @@
> > status = "okay";
> > };
> >
> > -&cps_i2c0 {
> > +&cps_spi1 {
> > status = "okay";
> > - clock-frequency = <10>;
> > +
> > + spi-flash@0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "jedec,spi-nor";
> > + reg = <0>;
> > + spi-max-frequency = <1
Re: [U-Boot] [PATCH v2 03/23] armv8: add lowlevel_init.S
On 05/12/16 21:56, Tom Rini wrote: > On Mon, Dec 05, 2016 at 01:52:10AM +, Andre Przywara wrote: > >> For boards that call s_init() when the SPL runs, we are expected to >> setup an early stack before calling this C function. >> Implement the proper AArch64 version of this based on the ARMv7 code. >> This allows sunxi boards to setup the basic peripherals even on with a >> 64-bit SPL. >> >> Signed-off-by: Andre Przywara > > This is going to override lowlevel_init from arch/arm/cpu/armv8/start.S > and is that really desired? Thanks! Not sure if it is desired, but it's needed. The weak function in start.S just initialises the GIC (if configured), that looks like a NOP for sunxi to me (we do this already much better in ARM Trusted Firmware). For 32-bit sunxi we call s_init() through lowlevel_init(), which is what I copy here for armv8. Now there is this comment which discourages doing so and Alex already complained about it as well, so I might take a look at how we would skip this step. I was a bit wary going there as this would mean to rework the 32-bit code as well, which affects a lot of boards, which I can barely test here. Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
